What is VEX, and why does it matter?
A vulnerable component does not automatically mean a vulnerable product. VEX is how that distinction gets stated formally — instead of being argued over email.
Once you have SBOMs and automated vulnerability analysis, you hit the second problem immediately: the list is enormous, and most of it does not matter. VEX is the mechanism for saying which parts do.
The problem VEX solves
Suppose a critical vulnerability is announced in a widely used parsing library. Your SBOM shows that library is present in one of your products. Three questions follow immediately, from three different directions:
- Your security team asks: are we actually exposed?
- Your customers ask: is the product we bought from you affected?
- You ask your vendors: is the software you supply us affected?
Often the honest answer is no. The vulnerable function is never called. The affected code path is unreachable in your configuration. The component is bundled but not loaded. The product is not exploitable, even though the component is vulnerable.
Without a formal way to say that, the answer lives in one engineer's head, gets retyped into a dozen email replies, and has to be reconstructed from scratch the next time someone asks.
What VEX is
VEX — Vulnerability Exploitability eXchange — is a structured statement about whether a specific vulnerability actually affects a specific product. It is machine-readable, it is attributable to whoever issued it, and it is durable: written once, it answers the question for everyone who asks afterwards.
Where an SBOM says what is in the software, VEX says what that means.
The statements VEX makes
A VEX statement pairs a product with a vulnerability and gives a status — broadly:
- Not affected — the vulnerability is present in a component but cannot be exploited in this product, with a stated reason.
- Affected — the product is genuinely exposed, and remediation guidance applies.
- Fixed — the product was affected, and this version resolves it.
- Under investigation — the question has been received and an answer is being worked on.
The "not affected" case is the one that carries the most value in day-to-day operations, because it is the one that removes work rather than creating it.
VEX requests: asking, not just telling
VEX is not only a broadcast. In SBOMAtlas a customer or organization can submit a formal VEX request — a tracked question asking whether a particular vulnerability is exploitable in a particular product.
The request moves through defined states: submitted, in review, and then fulfilled or rejected. The organization or vendor responds with a VEX statement, and both the question and the answer stay on the record.
That matters because it turns an inherently three-party conversation into a tracked workflow. A customer asks you. You may need to ask your vendor. Every step is visible, and nothing depends on someone remembering to follow up.
What changes in practice
Without VEX, every published CVE that touches a component in your inventory becomes a potential escalation, and the same exploitability question gets answered repeatedly by different people in different words.
With VEX, exploitability is determined once, recorded formally, and reused. Triage effort concentrates on findings that are actually exploitable. Customers receive a definitive answer instead of a hedge. And when an auditor asks how a given vulnerability was handled, the reasoning is already written down.
VEX and triage work together
Triage decides what happens to a finding — who owns it, when it is due, whether it is escalated or dismissed. VEX establishes whether the finding is real for a given product in the first place. Neither replaces the other, and together they are what separates a manageable queue from an unmanageable one.
In SBOMAtlas, both live in the same platform as the SBOMs and vulnerability data they refer to, so the statement, the evidence behind it, and the notification that carries it to a customer are never in three different systems.