VEX, short for Vulnerability Exploitability eXchange, is a machine-readable statement that says whether a specific known vulnerability affects a specific product. It lets a supplier tell customers "this scanner finding does not apply to us, and here is why," so people stop chasing alerts that cannot be exploited.
The problem VEX solves
A scanner sees a vulnerable library inside your product and raises an alert. But a library can be present and the flawed code never run. The customer cannot tell the difference from the outside, so they open tickets and email the supplier.
VEX is the supplier's reply in a form tools can read. CISA publishes a document describing the minimum elements needed to create a VEX document, derived from existing VEX documentation and implementations.
The four statuses
The OpenVEX specification, one implementation that meets the CISA minimum elements, defines four status values:
not_affected: no remediation is needed, and a justification or impact statement is required.affected: remediation or mitigation is recommended.fixed: the listed product versions contain a fix.under_investigation: it is not yet known whether the product is affected.
Other VEX formats may use different spellings, so check the one you receive.
Why "not affected" needs a reason
A bare "not affected" is just an opinion. OpenVEX asks for a justification, and it lists a fixed set:
- the vulnerable component is not present
- the component is present but the vulnerable code is not
- the vulnerable code cannot be executed by the product
- an attacker cannot control the vulnerable code
- built-in mitigations already prevent exploitation
Those reasons let a reader judge the claim instead of trusting it.
VEX and SBOM together
An SBOM says what is inside. VEX says what that means for known flaws. Used together, a buyer can take a supplier's inventory, match it to vulnerability data, then apply the supplier's VEX statements to remove the findings that do not apply. See what an SBOM is for the inventory half.
VEX is only as good as the analysis behind it. A supplier who marks everything "not affected" without evidence has added noise, not removed it.
Click through it at your own pace, or open it full screen.
Safeguard's reachability analysis produces the kind of evidence that supports an exploitability decision. A free scan is at gold.safeguard.sh/scan.
Quick check
Is VEX a replacement for patching?
No. It records that a flaw does not apply or that a fix exists. If the product is affected, you still need to fix or mitigate it.
Who writes a VEX statement?
Usually the supplier or maintainer of the product, since they know how the component is used inside it.
Sources
Last reviewed: 19 October 2026.
