Vendor statements of which CVEs actually affect which products.
VEX — Vulnerability Exploitability eXchange — is a machine-readable statement issued by a software producer that says, for each CVE affecting a component it ships, whether the product is actually affected, not affected, fixed, or under investigation, and why.
It is the companion document to an SBOM. The SBOM says "this product contains lodash 4.17.20." VEX says "CVE-2021-23337 is present in that dependency but our product is not affected because the vulnerable function is never called in our configuration." Standard formats include CycloneDX VEX, CSAF 2.0, and OpenVEX.
A VEX document is a list of statements, each with a CVE, a product identifier, a status, and — crucially — a justification:
affected, not_affected, fixed, or under_investigation. Each status has a precise meaning in the spec.not_affected). Standard enum values: component_not_present, vulnerable_code_not_present, vulnerable_code_cannot_be_controlled_by_adversary, vulnerable_code_not_in_execute_path, inline_mitigations_already_exist. Regulators expect one of these rather than a free-text excuse.Once consumers start scanning vendor SBOMs, every open CVE in every shipped dependency turns into a customer ticket. Most of those CVEs are not exploitable in the specific product configuration — but without a machine-readable answer, the vendor's support team fields the same email thousands of times.
VEX converts that thread into a signed document. The consumer's scanner automatically suppresses the noise, the vendor's support load drops, and both sides can point to a durable audit artifact. This is the only mechanism that makes SBOM adoption sustainable at scale.
Vendor-signed "not affected" statements automatically suppress findings in consumer scanners — the same CVE is not re-triaged across every customer.
Instead of answering the same CVE question in a thousand tickets, publish one VEX document and let consumer tooling read it.
Every "not affected" carries a spec-defined justification — exactly the kind of evidence a regulator or enterprise customer expects to see.
If your reachability analyzer proves the vulnerable function is unreachable, the matching VEX statement (vulnerable_code_not_in_execute_path) generates itself.
Without VEX, publishing SBOMs floods customers with false positives. With VEX, both documents are useful together — which is why regulators now co-mandate them.
Safeguard generates VEX statements automatically from reachability analysis output, stores them next to the relevant SBOM, and publishes them through the SBOM Studio distribution surface.
Point Safeguard at a product. Auto-generate VEX statements from reachability, signed and distributable.