VEX: exploitability
The problem VEX solves
An SBOM matched against vulnerability databases produces hundreds of alerts per product. A large majority are not exploitable in your context: the vulnerable code is not called, the function is not compiled in, a mitigation is in place.
With no mechanism to express that, there are two outcomes, both bad: either the team handles everything and burns out, or it suppresses the alerts and loses the record of its decisions. The second is exactly what an authority will look for.
The definition
VEX — vulnerability exploitability exchange — is a structured assertion by the supplier about the exploitability status of a given vulnerability in a given product.
It is not a competitor to the SBOM: it is a complement. The SBOM says what is inside; the VEX says what that implies.
The four statuses
| Status | Meaning | What else is expected |
|---|---|---|
not_affected |
The product is not affected | A standardised justification, mandatory |
affected |
The product is affected | A recommended action for the user |
fixed |
The vulnerability is fixed in this version | The fixed version |
under_investigation |
Analysis is in progress | A deadline, and an actual follow-up |
under_investigation is a temporary status. A VEX left under investigation for six months
is a process defect, not a position.
not_affected justifications
They are standardised, and that is what gives the mechanism its value:
| Justification | Meaning |
|---|---|
| component_not_present | The allegedly vulnerable component is not in the product |
| vulnerable_code_not_present | The component is present, but not the vulnerable portion of code |
| vulnerable_code_not_in_execute_path | The vulnerable code exists but is never executed |
| vulnerable_code_cannot_be_controlled_by_adversary | The code executes but an attacker cannot control its input |
| inline_mitigations_already_exist | An internal countermeasure neutralises exploitation |
A justification outside that list, or an empty one, is not acceptable.
The implementations
| Implementation | Steward | Typical use |
|---|---|---|
| CycloneDX VEX | OWASP | Same ecosystem as your pivot SBOM |
| OpenVEX | Community | Minimal, standalone, easy to generate and sign |
| CSAF 2.0, VEX profile | OASIS | Publishing machine-readable advisories to customers |
These implementations express the same notions. The choice follows the use: internal and tooled for CycloneDX or OpenVEX, external and standardised for CSAF.
The legal value
This is the point to land with Legal and Cyber at the same time.
Annex I, Part II, point 2 requires addressing and remediating vulnerabilities without delay. It does not require fixing every identifier a scanner reports. A vulnerability that has been analysed and declared non-exploitable, with a standardised justification, has been addressed.
A VEX is therefore the documentary form of a reasoned decision not to fix. It turns an engineering choice into a defensible record. Without it, the same decision is indistinguishable from negligence.
The internal process
| Step | Who | Output |
|---|---|---|
| Detection | Steering platform | Alert on a product / vulnerability pair |
| Exploitability analysis | Product engineering | Proposed status + justification |
| Review | PSIRT | Status approved or returned |
| Arbitration on disagreement | Committee, per the RACI matrix | Traced decision |
| Issuance | Automated chain | Signed, timestamped VEX document |
| Publication where relevant | PSIRT + Legal | Customer advisory, CSAF format |
| Re-examination | PSIRT | At every new product version |
A VEX belongs to a product and a version. It does not carry over automatically to the next version: re-examination is part of the process.
The link to security advisories
Annex I, Part II, point 4 requires publishing information about fixed vulnerabilities. The CSAF 2.0 format allows publishing both fix advisories and VEX assertions in a form your customers can process automatically — reducing their workload and yours.