A critical CVE hits a library everyone uses. Within hours, customers, auditors and procurement teams all ask the same question: is your product affected? Your SBOM tells you whether the component is in the product. It does not tell you whether the vulnerability can actually be exploited there. That second answer is what VEX is for.
What is VEX (Vulnerability Exploitability eXchange)?
VEX, short for Vulnerability Exploitability eXchange, is a machine-readable statement from a supplier saying whether a known vulnerability affects a specific product version, and why. Instead of “this component has a CVE”, a VEX says “in this product, this CVE is not exploitable, here is the justification”, or “it is, here is the fix”.
The concept came out of the NTIA software transparency work in the US and is now carried by CISA, which publishes minimum requirements for VEX documents. In practice, a VEX is produced by the manufacturer or its PSIRT, the only party that knows how a component is actually built into the product.
VEX vs SBOM: what is the difference?
An SBOM is an inventory: it lists the components and versions inside a product. A VEX is an assessment: it qualifies the impact of a given vulnerability on that product. One answers “what is in it?”, the other “should I worry about this CVE?”. VEX is only reliable when it sits on top of an accurate SBOM.
Here is how the two fit together with Log4Shell as an example:
- The SBOM shows that the product ships log4j-core 2.14.1.
- CVE-2021-44228 is published for log4j-core versions below 2.15.0.
- Matching the SBOM against the CVE confirms the version is in the affected range.
- An analyst checks whether the vulnerable code is present and reachable in this specific build.
- The supplier publishes a VEX statement: affected with a fix, or not affected with a justification.
Without step 5, every customer runs the same scanner, gets the same alert and opens the same support ticket.
The four VEX statuses
Every VEX statement assigns one of four statuses to a product and vulnerability pair:
| Status | What it means | What the customer should do |
|---|---|---|
| Not affected | The component may be present, but the vulnerability cannot be exploited in this product. A justification is required. | Nothing, and close the scanner alert. |
| Affected | The product is vulnerable. The statement should include an action: patch, upgrade or workaround. | Apply the recommended action, prioritized by severity. |
| Fixed | The vulnerability is resolved in a specific product version. | Upgrade to that version. |
| Under investigation | The supplier is still analyzing the issue. | Wait for an update and track the expected timeline. |
The five justifications for “not affected”
A “not affected” claim is only useful if it can be checked. CISA defines five standard justifications:
- Component not present: the vulnerable component is not in the product at all.
- Vulnerable code not present: the component is there, but the vulnerable code was removed or never compiled in.
- Vulnerable code not in execute path: the code exists but is never called.
- Vulnerable code cannot be controlled by an adversary: an attacker cannot reach or influence the vulnerable input.
- Inline mitigations already exist: built-in protections prevent exploitation.
VEX vs VDR
A Vulnerability Disclosure Report (VDR) lists every known vulnerability affecting a product and its current state, much like a security bill of health. A VEX focuses on exploitability and is most valuable for the negative answer: telling customers which scanner findings they can safely ignore. Many suppliers publish both, and CycloneDX can carry either.
VEX formats: CycloneDX, CSAF and OpenVEX
VEX is a concept, not a single file format. Three formats carry it today:
| Format | Maintained by | Best suited for |
|---|---|---|
| CycloneDX VEX | OWASP (standardized as ECMA-424) | Teams already producing CycloneDX SBOMs. VEX data can live in the SBOM or in a separate document. |
| CSAF VEX | OASIS (CSAF 2.0 VEX profile) | Formal security advisories. Used by the PSIRTs of large vendors such as Red Hat and Siemens. |
| OpenVEX | OpenSSF (created by Chainguard) | Lightweight statements and automation in CI pipelines, with tooling such as vexctl. |
The analysis is the same whichever format you export. Pick the one your customers and their tools already consume.
What a VEX statement looks like
A minimal OpenVEX document telling customers a product is not affected by Log4Shell:
{
"@context": "https://openvex.dev/ns/v0.2.0",
"@id": "https://example.com/vex/2026-0001",
"author": "Example Corp PSIRT",
"timestamp": "2026-10-15T09:00:00Z",
"version": 1,
"statements": [
{
"vulnerability": { "name": "CVE-2021-44228" },
"products": [ { "@id": "pkg:generic/example-gateway@3.2.0" } ],
"status": "not_affected",
"justification": "vulnerable_code_not_present",
"impact_statement": "The JndiLookup class is removed from the log4j-core JAR shipped in this firmware."
}
]
}Note the product identifier (a package URL with an exact version), the status and the justification. A statement without a precise version or a justification is hard to trust.
Is VEX required? US and EU context
In the US, no law mandates VEX. CISA guidance and federal buyers asking for SBOMs are pushing suppliers to answer the next question, which is exploitability.
In the EU, the Cyber Resilience Act (CRA) changes the timeline for manufacturers of products with digital elements. Since 11 September 2026, actively exploited vulnerabilities must be reported within 24 hours through the CRA single reporting platform, to the coordinating CSIRT and ENISA. From 11 December 2027, the full vulnerability handling requirements apply, including an SBOM and the obligation to inform users about vulnerabilities and fixes. The CRA does not name VEX, but answering those obligations product by product, version by version, is exactly the job VEX does.
How to set up a VEX process
A VEX process that holds up over time rests on four elements:
- An up-to-date SBOM for every product version. Without a precise inventory, impact analysis is guesswork.
- CVE monitoring matched against those SBOMs. New vulnerabilities should trigger an alert on every product and version that contains the component.
- A documented exploitability analysis. Someone who knows the product decides whether the vulnerable code is present and reachable, and records why.
- A publication channel. A security page, a CSAF feed or direct notices to the customers concerned, depending on severity.
Matching CVEs against SBOMs can be automated. The exploitability decision cannot: it needs product knowledge and a human who signs off on it. And “under investigation” should not become a parking spot: set internal targets, for example a final status within 48 hours for critical CVEs.
VEX FAQ
Who should issue a VEX?
The supplier of the product, usually its PSIRT or product security team. Only the manufacturer knows how a component is configured and used inside the product.
Does a VEX replace a security advisory?
No. A VEX is a structured, machine-readable statement that scanners and asset tools can consume. Advisories remain the human-readable explanation. CSAF can carry both.
How often should a VEX be updated?
Whenever the status changes: new analysis, new product version or new information about exploitation. A VEX is tied to a product version, so each release needs its own statements.
Is a VEX proof of compliance?
No. It is evidence that vulnerabilities are being assessed and communicated. Compliance with the CRA depends on the manufacturer’s overall process, not on a single document.