SBOM vs VEX: what each tells you and how they work together

An SBOM says a component is present. A VEX says whether a vulnerability in that component actually affects the product. Together they turn scanner noise into decisions.

Two different questions

An SBOM answers what is in this software? ^[1]. A Vulnerability Exploitability eXchange (VEX) document answers does this vulnerability affect this product? The distinction matters because a vulnerable component can be present without being exploitable: the vulnerable function may not be compiled in, may not be reachable or may be mitigated.

CISA's Minimum Requirements for VEX (April 2023) note that VEX is designed to integrate with SBOMs, vulnerability databases and advisories, "but does not require any of these" ^[2].

Side-by-side

VEX statuses and justifications

CISA defines four statuses: not_affected, affected, fixed and under_investigation ^[2]. A "not affected" statement needs a justification, chosen from:

• component_not_present
• vulnerable_code_not_present
• vulnerable_code_not_in_execute_path
• vulnerable_code_cannot_be_controlled_by_adversary
• inline_mitigations_already_exist

An "affected" statement must include an action statement describing remediation or mitigation ^[2]. CERT-In's guidelines use the same four statuses and recommend that suppliers publish VEX when a vulnerability is discovered, followed by a detailed advisory in CSAF ^[3][4].

Where VEX lives

• CycloneDX supports VEX either embedded in a BOM or as a standalone document ^[5].
• SPDX 3.0 includes VEX assessment relationships in its Security profile, such as VexAffected and VexNotAffected ^[6].
• CSAF 2.0 is an OASIS standard for machine-readable security advisories and includes a VEX profile ^[4].
• OpenVEX is a minimal, SBOM-format-agnostic JSON-LD implementation designed to meet CISA's minimum requirements ^[7].

Keeping VEX separate from the SBOM is often practical: the SBOM is fixed per version, while VEX statements change as analysis progresses. Germany's BSI TR-03183-2 excludes vulnerability data from the SBOM for this reason ^[8].

How they work together

1. The supplier ships an SBOM with each version.
2. A vulnerability is published; the consumer's tools match it to a component in the SBOM.
3. The supplier analyses impact and publishes a VEX statement for affected product versions.
4. The consumer imports the VEX. "Not affected" findings are suppressed with the justification recorded; "affected" findings are prioritised with the supplier's action statement.
5. When a fix ships, a new SBOM and a "fixed" VEX statement close the loop.

Operational pitfalls

• Unscoped statements. A VEX statement applies to specific product versions. Check that the versions in the VEX match the versions you run.
• Stale "under investigation". Track how long statements stay in this state and follow up with the supplier.
• Missing justification. A "not affected" claim without one of the standard justifications is hard to defend in an audit.
• Lost decisions. If VEX decisions are held only in a scanner's suppression list, they may be lost when the tool or the SBOM version changes.

For your own software, record internal VEX decisions too, so the same finding is not re-triaged with each scan. Tools such as Grype can use OpenVEX to filter scan results ^[9].

How IntelliXBOM helps

IntelliXBOM records VEX decisions against components and vulnerabilities, with status and justification, and carries them across SBOM versions. It correlates SBOM components with vulnerabilities and known-exploited lists so VEX effort goes to findings that matter, and includes decisions in timestamped evidence.