What is VEX? Vulnerability Exploitability eXchange explained

What is VEX? Vulnerability Exploitability eXchange is a machine-readable statement from a software supplier about whether a specific vulnerability in a specific product is actually exploitable. If the SBOM says what is inside, VEX says whether the scary thing inside can hurt you. Together they stop the most expensive ritual in supply chain security: every customer emailing every vendor "are you affected by CVE-XXXX?" after every headline vulnerability.

This guide covers:

What VEX is and the false-positive problem it exists to kill
The four standardized statuses and the justifications behind "not affected"
The competing VEX formats (CSAF, CycloneDX, OpenVEX) and how to choose
A workflow for issuing VEX statements without drowning your security team
When buyers and regulators expect VEX alongside SBOMs

Separating signal from noise

GIF via GIPHY

Related guides:

Key takeaways

VEX is a supplier assertion about exploitability, complementing the SBOM's component inventory.
The four statuses are Not affected, Affected, Fixed, and Under investigation—"not affected" requires a machine-readable justification.
The practical value: SBOM scans generate noise; VEX turns noise into a short list of things that matter.
Three formats compete (CSAF, CycloneDX VEX, OpenVEX); customer demand should drive your choice.
SecureSlate helps you run the triage and communication process VEX formalizes.

VEX in plain terms

When a customer scans your SBOM, the scanner flags every component version with a known CVE. Most flags are false alarms in context—the vulnerable function is never called, the component is compiled out, or a mitigation blocks the path. VEX is the standardized way to say so:

"Product X version 2.3 contains component Y. CVE-2026-1234 affects component Y. Status: not affected. Justification: vulnerable code is not present in the shipped build."

Because the statement is machine-readable, customer tooling can automatically suppress the finding—no email thread, no spreadsheet, no support ticket.

The problem VEX solves

Industry analyses have repeatedly found that the large majority of vulnerabilities flagged by naive SBOM scanning are not exploitable in the product's actual configuration. Without VEX:

Customers burn triage hours on findings the vendor already ruled out
Vendors answer the same "are you affected?" question hundreds of times per incident
Real exploitable issues drown in the noise

Log4Shell made this concrete: organizations that received VEX-style statements from vendors closed their exposure reviews in days; the rest ran manual campaigns for months.

The four VEX statuses

Status	Meaning	What follows
Not affected	The vulnerability cannot be exploited in this product	Requires a justification (below); customers suppress the finding
Affected	Exploitable; the product is impacted	Should include remediation or mitigation guidance
Fixed	Addressed in the referenced version	Customers upgrade
Under investigation	Analysis in progress	Statement is updated when concluded

The standardized "not affected" justifications carry the weight: component not present, vulnerable code not present, vulnerable code not in execute path, vulnerable code cannot be controlled by adversary, or inline mitigations already exist. Precise justifications are what make the statement credible—and defensible.

VEX formats

CSAF — OASIS's Common Security Advisory Framework with a VEX profile; favored in enterprise and government advisory ecosystems (CISA publishes guidance around it)
CycloneDX VEX — native to the CycloneDX BOM family; the natural choice if your SBOMs are CycloneDX
OpenVEX — a minimal, implementation-friendly specification originating from the open source community

There is no single winner yet. Pragmatically: if your SBOMs are CycloneDX, start there; if federal or large-enterprise customers dominate, expect CSAF requests. The underlying analysis is identical—format is an export decision.

A practical VEX workflow

New CVE published → your monitoring platform matches it against stored SBOMs (see SBOM best practices).
Security engineering triages exploitability: is the code present, reachable, adversary-controllable in the shipped configuration?
Record the determination with one of the four statuses and, for "not affected," a standardized justification.
Publish the VEX statement through your trust center, customer portal, or advisory feed.
Update as facts change—"under investigation" statements must be revisited, and every fix ships with a "fixed" statement.

For high-visibility CVEs, aim to publish an initial statement (even "under investigation") within 24–72 hours—buyers judge responsiveness as much as the answer.

When customers expect VEX

Enterprise security questionnaires increasingly ask whether you provide VEX or equivalent exploitability statements
Federal buyers reference VEX in supply chain guidance descended from EO 14028
Medical device customers expect exploitability analysis in postmarket vulnerability communication—CycloneDX VEX pairs naturally with FDA SBOM submissions
After any headline CVE, every customer with your SBOM effectively expects one, whether or not the contract says so

VEX, SBOMs, and compliance with SecureSlate

SecureSlate helps you operate the machinery behind credible VEX statements—vulnerability triage with SLAs, documented determinations, and customer-facing trust artifacts—mapped to SOC 2 and ISO 27001 evidence.

Get started for free · Free readiness score

FAQ: VEX

Is VEX required by regulation?

Not broadly mandated today, but U.S. federal guidance encourages it, FDA expects exploitability analysis in device vulnerability handling, and buyer questionnaires are making it a de facto requirement.

Can VEX statements be wrong?

Yes—and a wrong "not affected" is a liability. Treat determinations like engineering decisions: documented rationale, a named analyst, and review for high-severity CVEs.

Do we need VEX if we patch everything quickly?

VEX still saves you the communication burden—"fixed in v2.4" as a machine-readable statement beats answering the same ticket 200 times.

Who writes VEX statements?

Security engineering typically makes the exploitability call; GRC or product security publishes and tracks statements. The analysis skill is reachability assessment, not document formatting.

How does VEX relate to the SBOM's "known unknowns"?

They are complementary honesty mechanisms: the SBOM declares inventory gaps; VEX declares exploitability conclusions about the inventory you did capture.

Disclaimer (legal note)

SecureSlate is not a law firm, and this article does not constitute legal advice or create an attorney-client relationship. Security and compliance obligations vary by industry, contract, and jurisdiction—consult qualified counsel as needed.