In depth
A Vulnerability Exploitability eXchange (VEX) document is a structured statement, issued by a software supplier, that communicates whether a known CVE is actually exploitable in their product. The premise: when a customer scans a vendor's product against their SBOM and finds CVE-2024-XXXXX flagged in a bundled dependency, the customer needs to know whether the vulnerable code path is reachable in that vendor's actual usage. Without VEX, the customer files an urgent ticket and the vendor's support team spends a day explaining "yes we ship that library but we never call the affected function." With VEX, the answer is machine-readable, signed by the vendor, and automatically consumed by the customer's vulnerability-management platform.
VEX statements carry one of four status values for each (product, vulnerability) pair. Not Affected means the vulnerable code is present but not reachable, with a justification code such as "vulnerable_code_not_in_execute_path" or "inline_mitigations_already_exist." Affected means the vulnerability is real and exploitable, paired with required action statements. Fixed means a patched version is available. Under Investigation means the vendor is triaging and a definitive statement will follow.
The two dominant VEX formats are CSAF VEX (the OASIS-standard format, machine-readable JSON, signed) and OpenVEX (a lightweight CycloneDX-compatible alternative from the Linux Foundation). CycloneDX itself also embeds VEX statements natively. CISA's "Minimum Requirements for VEX" guidance specifies the data fields that any VEX document must contain to be useful in a federal-procurement context.
Practically, VEX transforms an unmanageable vulnerability backlog into a triaged work queue. An enterprise running an SBOM against the NVD might surface 4,000 CVEs in a typical SaaS product's dependency graph; VEX statements from the vendor typically reduce the actionable list to fewer than 50. This is the difference between a vulnerability-management programme that scales and one that drowns its engineers. See supply chain attacks 2026.
VEX statements carry one of four status values for each (product, vulnerability) pair. Not Affected means the vulnerable code is present but not reachable, with a justification code such as "vulnerable_code_not_in_execute_path" or "inline_mitigations_already_exist." Affected means the vulnerability is real and exploitable, paired with required action statements. Fixed means a patched version is available. Under Investigation means the vendor is triaging and a definitive statement will follow.
The two dominant VEX formats are CSAF VEX (the OASIS-standard format, machine-readable JSON, signed) and OpenVEX (a lightweight CycloneDX-compatible alternative from the Linux Foundation). CycloneDX itself also embeds VEX statements natively. CISA's "Minimum Requirements for VEX" guidance specifies the data fields that any VEX document must contain to be useful in a federal-procurement context.
Practically, VEX transforms an unmanageable vulnerability backlog into a triaged work queue. An enterprise running an SBOM against the NVD might surface 4,000 CVEs in a typical SaaS product's dependency graph; VEX statements from the vendor typically reduce the actionable list to fewer than 50. This is the difference between a vulnerability-management programme that scales and one that drowns its engineers. See supply chain attacks 2026.