VEX — Vulnerability Exploitability eXchange

A VEX (Vulnerability Exploitability eXchange) document is a machine-readable security statement that communicates a manufacturer's assessment of whether a specific CVE is exploitable in the context of a specific product version. VEX addresses a fundamental challenge in SBOM-based vulnerability management: a component may be listed as vulnerable in the NVD, but the vulnerable function may not be compiled in, may not be reachable via any code path, or may be mitigated by the product's architecture. VEX provides four status values: Not Affected, Affected, Fixed, and Under Investigation — allowing manufacturers to give precise, actionable exploitability statements rather than leaving users to assume every CVE in their component list is a live risk.

The CRA requires manufacturers to communicate information about identified vulnerabilities and available remediations to users. VEX provides the standardised, machine-readable mechanism for this communication — enabling downstream users (enterprises, system integrators, distributors) to automatically process the manufacturer's exploitability assessments without manual review. For manufacturers with complex products containing hundreds of open-source components, VEX also reduces the operational burden of vulnerability management: instead of being pressured to patch every CVE in an SBOM regardless of exploitability, manufacturers can formally communicate 'Not Affected' status with justification, reducing user anxiety and support burden while focusing engineering effort on genuinely exploitable vulnerabilities.

VEX documents can be generated as standalone files or embedded within CSAF (Common Security Advisory Framework) documents or CycloneDX SBOMs. The CSAF standard includes a VEX profile, making it the most common format for EU regulatory contexts. Manufacturers should generate VEX statements as part of their routine vulnerability management workflow: when SCA scanning identifies a CVE in a component, the PSIRT team assesses exploitability, assigns a VEX status with a justification, and publishes the VEX document alongside or within the relevant SBOM or CSAF advisory. VEX documents should be versioned and updated as exploitability status changes — for example, if a 'Not Affected' determination is later found to be incorrect due to a different attack vector being discovered.

A critical mistake is issuing 'Not Affected' VEX statements without conducting a genuine exploitability analysis — simply to reduce the visible vulnerability count in SBOM reports. This constitutes misrepresentation to users and may constitute non-compliance with the CRA's requirement to provide accurate vulnerability information. Manufacturers must document the justification for 'Not Affected' determinations: CISA's VEX guidance provides specific justification categories (component not present, vulnerable code not in execution path, vulnerable code not reachable, inline mitigations exist). A second error is treating VEX as a one-time document rather than a living artefact that must be updated when new attack paths are discovered.