A VEX, or Vulnerability Exploitability eXchange, is a machine-readable statement from a supplier about whether a known vulnerability in a component actually affects their product. Ask for one when your scanner flags a supplier's software and you need to know if the flag matters.
The problem it solves
You receive a partner's SBOM and run it through a scanner. It returns a long list of CVEs. Most of those components may be present but unused, or protected by how the product is configured. Without a statement from the supplier, you must either chase every one or ignore them all.
CycloneDX describes VEX as a way to convey the exploitability of vulnerable components in the context of the product in which they are used. CISA's SBOM page describes VEX as an attestation that indicates whether products are affected by known vulnerabilities.
What a VEX contains
In general terms, a VEX links a vulnerability identifier to a product and a status. Common statuses across VEX formats are that the product is affected, not affected, fixed, or under investigation. The exact vocabulary differs by format, so check the specification your supplier uses. A good statement for a not affected claim also gives a justification, such as the vulnerable code not being present or not being reachable.
When to ask for one
- After you scan a supplier's SBOM and see findings you cannot assess yourself.
- When a high profile vulnerability lands and your customers ask about a product you resell or embed.
- During diligence, to see how the target talks to its own customers about exposure.
How to read what comes back
| Status | What to do |
|---|---|
| Not affected with justification | Spot check the reasoning, then accept |
| Affected, fix available | Plan the update with the supplier |
| Affected, no fix | Ask for mitigations and a date |
| Under investigation | Set a follow up date |
| Not affected, no reason given | Ask for the reason |
A VEX is a claim by the supplier, not an independent test. Treat it the way you treat any vendor statement: useful, and worth sampling.
How suppliers produce them
Writing a VEX by hand does not scale. Teams that do it well rely on reachability analysis to decide which flaws their code can actually trigger, then record the decision once and publish it alongside each release. That also makes your own customer conversations shorter.
Try it yourself
Open the demo to see how exploitability is assessed for a single finding. Notice the evidence the check shows for and against exploitation.
Click through it at your own pace, or open it full screen.
Safeguard's reachability analysis supports this kind of decision for your own software, and a free scan shows how findings look before and after filtering.
Quick check
Is a VEX the same as an SBOM?
No. An SBOM lists components. A VEX says whether specific vulnerabilities in those components affect the product.
Can I rely on a VEX to skip scanning?
No. Keep scanning. A VEX tells you how to read the results.
Sources
Last reviewed: 19 October 2026.
