VEX (Vulnerability Exploitability eXchange)
A VEX document states whether a product is affected by a known vulnerability. The four statuses, the not_affected reasons, and how VEX pairs with an SBOM.
A VEX (Vulnerability Exploitability eXchange) document is a supplier's statement about whether a product is affected by a specific known vulnerability. CISA published minimum requirements for VEX in 2023.
What it is
Each VEX statement ties a vulnerability to a product and gives it one of four statuses. In the OpenVEX specification they are:
- not_affected: needs a justification or an impact statement.
- affected: should say what to do about it.
- fixed: the vulnerability is fixed in this version.
- under_investigation: not known yet.
OpenVEX lists five justifications for not_affected, for example component_not_present, vulnerable_code_not_present and vulnerable_code_not_in_execute_path. VEX can also be written in CycloneDX.
Why it matters
An SBOM tells you which components a product contains. Matched against vulnerability databases, that list produces many alerts, and a lot of them are in code the product never calls. VEX is the supplier's answer to "does this one actually affect us?", so security teams can spend their time on the alerts that matter.
In AI CodeOps
AI CodeOps doesn't generate or consume VEX documents. It stores the SBOMs you produce for each project and uses their license data in the release gate.
Frequently asked questions
Why not just fix every CVE a scanner reports?
Many reported CVEs sit in code your product never runs. A VEX statement records that judgement once, with a reason, so every downstream user doesn't have to redo it.
Does AI CodeOps produce VEX documents?
No. It doesn't generate or read VEX today.