VEX , Vulnerability Exploitability eXchange

Vulnerability Exploitability eXchange , VEX , is a structured data format that allows software vendors to communicate to their customers which known vulnerabilities affecting their software components are actually exploitable in the context of their specific product. SBOM and SCA tools identify every component and flag every known CVE associated with those components , producing vulnerability lists that are technically accurate but operationally overwhelming. A software product that uses 500 open-source components will have hundreds or thousands of associated CVEs. The majority of those CVEs will affect code paths that the product never executes, library features the product never calls, or configurations the product does not use. VEX provides the mechanism for the vendor to communicate this context , distinguishing the vulnerabilities that require customer action from the vulnerabilities that are present in the code but not exploitable in the product.

The VEX statement structure defines four dispositions for any known vulnerability in a product: Not Affected (the product is not affected by the vulnerability), Affected (the product is affected and action is required), Fixed (the vulnerability has been fixed in a specific version), or Under Investigation (the vendor is determining the impact). These dispositions transform a raw vulnerability count into an actionable remediation picture. A product with 312 flagged CVEs and VEX statements showing 289 as Not Affected and 23 as Affected requires fundamentally different triage effort than 312 undifferentiated vulnerabilities.

The producer-consumer trust model is the limitation that VEX must be assessed within. VEX statements are produced by the software vendor , the same party whose software contains the vulnerabilities. A vendor who asserts that 289 of their 312 flagged CVEs are Not Affected may be accurate, or may be underweighting exploitability to reduce their remediation burden. VEX statements should be accompanied by justification , the specific reason the vulnerability is assessed as not exploitable , that allows the consumer to evaluate the assessment rather than simply trusting it.

Why this matters

VEX matters for TPRM because without it, enterprises either triage large vulnerability lists manually , an expensive and slow process , or apply blanket risk acceptance to unflagged vulnerabilities that may or may not be exploitable. VEX provides the vendor context that enables risk-proportionate triage: focusing remediation effort on the vulnerabilities that are actually exploitable in the product's deployment context.

• SCA findings without VEX require manual triage of all flagged vulnerabilities
• Exploitable vs non-exploitable vulnerabilities not distinguished without VEX
• Vendor exploitability assessment not provided alongside SBOM
• VEX not requested in vendor software security assessment
• Risk acceptance applied blanket to untriaged vulnerabilities

What good looks like

Mature VEX programmes request VEX documents alongside SBOMs for critical software, validate VEX Not Affected statements by reviewing the justifications, and use VEX-informed triage to prioritise remediation for Affected and Under Investigation dispositions.

• Request VEX alongside SBOM for critical software vendors
• Review Not Affected justifications , not just accepting the disposition
• Prioritise Affected and Under Investigation for remediation action
• Track VEX updates as vendor-side remediation progresses
• Include VEX in software supply chain assessment requirements

Tooling

VEX , OpenVEX specification; CycloneDX VEX; CISA VEX working group guidance

VEX is currently implemented in two primary formats: OpenVEX (a standalone VEX format) and CycloneDX VEX (VEX embedded in or linked from a CycloneDX SBOM). Dependency-Track and other SBOM management tools can ingest both formats and apply VEX dispositions to filter vulnerability findings. For TPRM practitioners, requesting CycloneDX format VEX from vendors aligns with the most widely implemented standard.

Governance challenges

The governance challenge with VEX is the producer quality problem. Vendors who generate VEX documents without adequate analysis , asserting Not Affected for all unflagged CVEs without actually validating exploitability , produce VEX that provides false assurance. The governance resolution is requiring justifications with VEX statements and sampling the Not Affected assessments to verify the vendor's reasoning.

• Require VEX with justifications , not just dispositions
• Sample Not Affected statements for validation against vendor reasoning
• Request VEX update cadence , how frequently VEX is updated as new CVEs are published
• Track Affected dispositions for vendor remediation progress
• Include VEX in SBOM requirements for critical software vendors

If you are a small team

For your highest-risk software vendor, request their VEX document for their current release alongside the SBOM. If they do not provide VEX, ask them to identify which of the SCA-flagged vulnerabilities in their SBOM are actually exploitable in the product as deployed , and which are not exploitable because of the specific code paths, configurations, or library features the product uses. That question, even without formal VEX format, captures the essential VEX intelligence and reveals whether the vendor has done the exploitability analysis.

• Request VEX alongside SBOM for highest-risk software vendor
• If VEX unavailable, ask vendor to identify exploitable vs non-exploitable CVEs
• Review Not Affected justifications for a sample of statements
• Track Affected dispositions for remediation progress

What to require

Ask directly:

"Can you provide VEX documentation alongside your SBOM , specifically identifying which of the flagged CVEs are actually exploitable in your product as deployed, with justification for Not Affected assessments?"

Expect as evidence

• VEX document in OpenVEX or CycloneDX VEX format
• Justifications for Not Affected dispositions
• Affected disposition list with remediation timeline
• VEX update cadence commitment

A vendor who provides an SBOM should be asked for VEX alongside it. SBOM lists what is present. VEX identifies what requires action. Both are required for actionable vulnerability management.

How to evidence it

• VEX request and receipt records
• Not Affected justification review
• Affected disposition remediation tracking
• VEX update monitoring

Key Takeaway

312 SCA findings. VEX: not available. Triage: 3 weeks to identify 23 exploitable and 289 not exploitable in context. VEX would have answered in minutes. SCA identifies every component and every CVE associated with it , technically accurate, operationally overwhelming. VEX provides the vendor's exploitability context , distinguishing what requires action from what is present but not reachable. SBOM lists the components. VEX identifies the actionable vulnerabilities within them. Both are required for supply chain vulnerability management at scale.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security