VEX, explained: telling customers which CVEs actually matter

Here is a scenario every security team knows. You run a scanner against your product's SBOM. It returns 600 vulnerabilities. You investigate and find that the large majority are not actually exploitable — the vulnerable code is never called, or a compensating control neutralizes it. Now you have a new problem: how do you communicate "this CVE is present but does not affect us" to a customer, an auditor, or a regulator, in a way a machine can read? That is what VEX is for.

What VEX is

VEX stands for Vulnerability Exploitability eXchange. A VEX document is a machine-readable statement about whether a specific vulnerability actually affects a specific product. It answers a question a raw vulnerability scan cannot: not "is this CVE present?" but "does this CVE matter here?"

A VEX statement assigns each vulnerability one of a small set of status values:

1. Not affected — the vulnerability is present in a component but is not exploitable in this product, with a stated reason.
2. Affected — the product is impacted and action is recommended.
3. Fixed — the vulnerability was present and has been remediated.
4. Under investigation — you are still determining the status.

Why "not affected" is the important one

The "not affected" status is the reason VEX exists. Without it, every component-level CVE looks like a live threat to anyone reading your SBOM. With it, you can say — credibly and at scale — "yes, that library is in our product; no, the vulnerable function is never reachable; here is why."

The standard even encodes why something is not affected: the vulnerable code is not present, not in the execution path, cannot be controlled by an attacker, or is mitigated by an existing control. That justification is what turns a bare assertion into something an auditor will accept.

The signal-to-noise problem VEX solves

Modern vulnerability scanning has an inflation problem. Scanners are tuned to over-report, because a false negative is worse than a false positive. The result is hundreds of findings, most of which are noise for any given product. That noise has real costs:

• Engineering time wasted triaging non-issues.
• Alert fatigue that causes real vulnerabilities to be missed.
• Customers who receive your SBOM, run their own scan, and flood you with questions about CVEs you already knew were irrelevant.

VEX is the antidote. It lets the producer of the software — who knows best whether a vulnerability is reachable — communicate that judgment once, in a form that travels with the SBOM and can be consumed automatically.

VEX and SBOMs are a pair

An SBOM tells you what is in the software. A VEX tells you which of the known vulnerabilities in those components actually matter. They are designed to work together: CycloneDX, for instance, can carry VEX information natively alongside the component inventory. The workflow looks like this:

1. Generate an SBOM for the product.
2. Match its components against vulnerability databases.
3. Triage the results — determine which are genuinely exploitable.
4. Record your conclusions as VEX statements.
5. Share the SBOM and VEX together, so consumers inherit your analysis instead of redoing it.

The honest caveat

VEX is only as trustworthy as the analysis behind it. A "not affected" status with a flimsy justification is worse than no statement at all, because it manufactures false confidence. The value of VEX is real, but it rests on disciplined triage — ideally backed by reachability analysis rather than gut feel. Done well, it is one of the highest-leverage things a security team can produce: it turns a wall of red into a short, honest list of what truly needs attention.