What is VEX?
Stating whether a CVE really affects your product.
VEX (Vulnerability Exploitability eXchange) is a machine-readable statement about whether a known vulnerability is actually exploitable in a specific product — and if not, why. It turns the noise of a scan into information that is useful to your customers and auditors.
VEX in one sentence
VEX = Vulnerability Exploitability eXchange. A structured, supplier-issued assertion that states whether a known CVE is exploitable in a specific product, and provides a justification when it is not.
A component scan (SBOM) reports every known vulnerability in the libraries a product contains. But a vulnerability present in a component is not always exploitable in the final product: the vulnerable code may be absent from the build, disabled, or unreachable. VEX exists precisely to document that distinction.
A concrete example. When the Log4Shell vulnerability is published, a VEX lets you state: "our product uses Log4j, but the vulnerable functionality is disabled — not exploitable." The customer can then suppress the finding, with an auditable justification, without you having to disclose your internal architecture.
The four VEX statuses
A VEX statement assigns each vulnerability one of four exploitability statuses. The "not affected" status always requires a machine-readable justification, so the consumer can audit the claim.
| Status | Meaning | What follows |
|---|---|---|
| Not affected | The vulnerability cannot be exploited in this product | A justification is required; customers suppress the finding |
| Affected | The vulnerability is exploitable; the product is impacted | Should include remediation or mitigation guidance |
| Fixed | Addressed in the referenced version | Customers upgrade |
| Under investigation | Analysis is in progress | A holding status, updated once the analysis concludes |
CycloneDX, OpenVEX or CSAF?
Three machine-readable formats coexist. They all carry the same core information — a product, a vulnerability, a status, a justification — and they interoperate. The choice mostly depends on your ecosystem and on what your customers ask for.
CycloneDX VEX
VEX can live in the same document as the SBOM. Ideal if you already generate CycloneDX SBOMs: inventory and exploitability travel together.
OpenVEX
A minimal, standalone, easily-signed statement. Suited to publishing simple, verifiable VEX assertions independently of the SBOM.
CSAF VEX
A profile of the CSAF standard, expressed as a structured security advisory. Expected by large enterprises and public-sector customers that publish machine-readable advisories.
VEX and SBOM: two complementary documents
The SBOM (Software Bill of Materials) is the inventory of a product's components: it says what the product contains. VEX says whether the vulnerabilities in those components are exploitable in the product. One does not replace the other.
In practice: the SBOM is the basis for analysis. Cross-referenced with known CVEs, it produces a list of potential vulnerabilities — often long and noisy. VEX is the layer that turns that noise into a short list of what actually matters: what is genuinely exploitable, and what is not, with a justification.
From CVE to decision
A CVE is a published vulnerability. It becomes exploitable — or not — depending on the product context. VEX is the document that carries that triage decision, in a machine-readable and auditable form.
Producing VEX grounded in the real product
A VEX is only valuable if it is connected to the right product, the right version and the right component. VAST structures that knowledge: Projects, Assets, inventory, versions and dependencies. When a CVE appears, the context needed to decide — and to justify — is already in place.
VAST helps generate VEX statements connected to this product knowledge, with traceability of decisions over time. The exploitability decision itself remains explicit and under your teams' control: VAST structures the information, it does not replace security judgment.
Frequently asked questions about VEX
The SBOM lists a product's components; VEX states whether the vulnerabilities in those components are exploitable in the product. The SBOM is the inventory, VEX is the exploitability analysis built on top of it.
Four statuses: not affected, affected, fixed, and under investigation. The "not affected" status requires a machine-readable justification so the customer can audit the claim.
It is the reason, drawn from a controlled vocabulary, why a vulnerability is not exploitable — for example "code not present in the build" or "vulnerable code not reachable." It makes the "not affected" claim verifiable.
The three formats (CycloneDX VEX, OpenVEX, CSAF) carry the same information and interoperate. If you already produce CycloneDX SBOMs, CycloneDX VEX is natural. If your customers are large enterprises or public sector, CSAF is often expected. The format is an export decision, not an analysis one.
VEX is a useful tool within a CRA process: it helps document the exploitability of a product's vulnerabilities and communicate that information in a structured way. It is not, on its own, proof of compliance: compliance depends on the manufacturer's overall process.
Connect your VEX to the knowledge of your products.
Starting from an Asset and its versions, VAST brings together the context needed to decide whether a CVE is exploitable — then to document it.