Software supply chain assurance: components to release

VEX and SBOM: check the supplier assertion’s scope

An SBOM describes components; VEX expresses an impact status for a vulnerability and identified products. This reference uses OpenVEX v0.2.0 labels. It offers no automatic conversion to CSAF or CycloneDX, whose structures need reading in their own versions.

Issuer, product identity and time are essential to interpretation. Product or time information can be inherited under OpenVEX rules; an absent statement field does not necessarily mean missing information in the complete document. Check resolved values before concluding.

Four OpenVEX statuses and their scope

For not_affected, the OpenVEX structure requires a justification or impact_statement; the format recommends a machine-readable justification, optionally enriched by text. For affected, an action_statement is required. These fields document an assertion rather than automatically establishing issuer trust.

Five justifications requiring different evidence

Fictional JSON example: an assertion for build 2.4.0

A training example written for this reference, with identifier TRAINING-VULN-01 and an .example domain. It describes no real product or vulnerability, is unsigned and has not been validated by an OpenVEX compliance engine. Its single statement inherits the document timestamp.

{
    "@context": "https://openvex.dev/ns/v0.2.0",
    "@id": "https://vendor.example/vex/training-01",
    "author": "Fictional training publisher",
    "timestamp": "2026-10-22T10:00:00Z",
    "version": 1,
    "statements": [
        {
            "vulnerability": {
                "name": "TRAINING-VULN-01"
            },
            "products": [
                {
                    "@id": "https://vendor.example/products/gateway/2.4.0"
                }
            ],
            "status": "not_affected",
            "justification": "vulnerable_code_not_present",
            "impact_statement": "Fictional training statement: the affected code was excluded from this exact product build."
        }
    ]
}

This assertion concerns only the product identified as version 2.4.0. It does not automatically cover 2.3.0, another distribution or a different configuration. The code-exclusion assertion still needs comparison with evidence and the trust placed in the issuer.

Six checks before using VEX to reduce alerts

• Identify the issuer and how the document was obtained; separate provenance, any signature and trust.
• Resolve product, subcomponents and identifiers to the deployed build.
• Check vulnerability identity and aliases rather than matching flaws by similar titles.
• Read status, required justifications or actions and product-specific conditions.
• Resolve inherited times and preserve document version; product changes may invalidate an older assumption.
• Record the acceptance decision, owner and conditions triggering review.

Return to prioritisation signals and remediation evidence →

Primary sources and scope

• OpenVEX · Specification v0.2.0 · OpenVEX v0.2.0 · reviewed 2026-10-22
  Statement Data Structure · Status Labels · Status Justifications · Data Inheritance

Sources checked on 2026-10-22