What is VEX? Vulnerability exploitability exchange, explained
A VEX statement says, in machine-readable form, whether a product is actually affected by a given vulnerability in one of its components: affected, not affected with a justification, fixed, or under investigation. It is the answer key that makes SBOM-based vulnerability matching usable at scale.
VEX, vulnerability exploitability exchange, is a machine-readable way of stating whether a product is actually affected by a vulnerability in one of its components. It exists because of an arithmetic problem that everyone who operationalizes SBOMs hits immediately: match a real application’s component inventory against vulnerability databases and you get hundreds of hits, most of which do not matter for this product, in this configuration, on this code path.
VEX is the standardized answer to “which of these actually matter,” from the party best placed to know.
What a VEX statement says
Each statement links a product, a component, and a vulnerability, and assigns a status:
- Affected: the vulnerability applies; remediation or mitigation guidance may be attached.
- Not affected: the product is not exploitable, with a standardized justification, for example the vulnerable code is not present, or is present but not in the execute path, or an inline mitigation already protects it.
- Fixed: addressed in this version.
- Under investigation: acknowledged, verdict pending.
The justifications are the load-bearing part. “Not affected: vulnerable_code_not_in_execute_path” is an auditable claim someone can verify; a bare “ignore this one” is not. This is what makes VEX suppression fundamentally different from a hide button.
Who produces VEX, and who consumes it
Suppliers issue VEX alongside advisories so every downstream customer does not independently investigate the same CVE against the same product. Consumers ingest supplier VEX to silence confirmed non-issues automatically, and issue their own internal VEX when their security team triages a finding: recording not just the decision but its justification, durably.
Done well, triage decisions and VEX become the same thing: a suppression in your vulnerability workflow is a VEX statement, keyed to stable identifiers, surviving rescans, exportable to anyone downstream who needs to honor the same decision. That loop, ingest upstream VEX, emit your own, is how large estates keep component-level matching honest without drowning.
The practical rules
- Key VEX to the same identifiers as your SBOM, or statements will not match the inventory they describe.
- Demand justifications, from vendors and from your own triage. Statuses without reasons decay into folklore.
- Treat VEX as living data: an under-investigation becomes an affected or a not-affected; a not-affected can be invalidated by a code change. Statements need identity and lifecycle, exactly like findings do.
In the SecuNexa platform, suppressions are VEX statements natively: justified, fingerprint-keyed, audit-logged, and exported in standard formats, and BOMNexa both ingests supplier VEX and emits yours with every managed BOM.
Frequently asked questions
Why do SBOMs need VEX?
Because component-level matching over-reports by design: containing a vulnerable component is not the same as being exploitable through it. VEX lets the party who knows, usually the supplier, state which findings are real for this product, with justifications, in a form tools can consume automatically.
What are the main VEX statuses?
Affected, not affected, fixed, and under investigation. The not-affected status carries standardized justifications, such as the vulnerable code not being present or not being in the execute path, which is what makes the statement auditable rather than a bare assertion.
Which formats carry VEX?
The two you will encounter are OpenVEX and CycloneDX's VEX capability; advisory formats like CSAF also carry exploitability information. What matters in practice is that your tooling can emit and consume at least one of them, keyed to the same component identifiers as your SBOM.