Vulnerability Exploitability eXchange (VEX)

VEX is a machine-readable statement about whether a known vulnerability actually affects a specific product. This page covers the four statuses and how VEX relates to SBOMs and VDR.

What is VEX

A Vulnerability Exploitability eXchange (VEX) statement lets a software supplier declare whether a known vulnerability in a component affects their product. VEX documents are machine-readable and delivered separately from the SBOM.

An SBOM lists every component in a product. Vulnerability scanners match those components against CVE databases and produce a list of potential exposures. But a CVE in a component does not mean the product is vulnerable. The vulnerable code path may be unreachable, or a mitigating configuration may neutralize the issue.

Without VEX, every CVE match triggers manual investigation by the consumer. VEX lets the supplier perform that analysis once and communicate the result to all downstream consumers, replacing per-consumer investigation with a single authoritative assessment.

VEX statuses

Every VEX statement assigns one of four statuses to a product-vulnerability pair, as defined by the CISA minimum requirements for VEX:

Not affected. The vulnerability does not affect this product. A justification is required: the vulnerable code is not present, the code path is not reachable, the code cannot be controlled by an adversary, inline mitigations exist, or a required dependency is absent.
Affected. The vulnerability affects this product. The supplier typically includes a recommended action such as an update, workaround, or mitigation.
Fixed. The vulnerability was present but has been remediated. The statement identifies the version containing the fix.
Under investigation. Analysis is ongoing. The supplier has not yet determined whether the product is affected.

The VEX Requirements section defines the fields, justifications, and content expectations for each status.

VEX is dynamic

SBOMs describe a software release at the time it was built. They are static artifacts. VEX documents track the relationship between a product and a vulnerability as analysis progresses.

A single vulnerability often moves through multiple statuses. A new CVE disclosure triggers an under_investigation statement. Analysis determines the product is affected. A patch release moves the status to fixed. Each transition produces a new VEX document for the same product-vulnerability pair.

Consumers must process updated VEX statements as analysis progresses and statuses change. Producers need a workflow that tracks open investigations and triggers new statements when analysis completes or patches ship. The Workflows section cover these processes.

VEX formats

Three standards support VEX:

CycloneDX. Embeds VEX assessments in the vulnerabilities array of a BOM document. Developed by the OWASP Foundation, standardized as ECMA-424.
CSAF. The Common Security Advisory Framework, an OASIS standard. CSAF defines a VEX profile within a broader advisory format used in regulated industries.
SPDX. Supports vulnerability information through its security extension. Developed by the Linux Foundation, standardized as ISO/IEC 5962:2021.

The Formats and Encoding page covers accepted versions and alignment rules between SBOM and VEX standards.

VEX and VDR

A Vulnerability Disclosure Report (VDR) documents all known vulnerabilities in a product's components, including vulnerabilities not yet published in public databases. VEX is narrower: it communicates whether specific known vulnerabilities affect the product.

A supplier may issue both. The VDR provides a complete vulnerability inventory; VEX statements provide exploitability assessments for individual CVEs. The VDR Requirements section covers VDR content expectations.

SBOM. The component inventory that VEX references when identifying affected products.