OpenVEX is a minimal, embeddable implementation of Vulnerability Exploitability eXchange (VEX) — a document that tells users of a software product whether a vulnerability found in one of its components actually affects it. It is designed to meet the minimum VEX requirements published by the CISA-coordinated VEX working group and to work independently of any SBOM format. Documents are serialized as JSON-LD. Version 0.2.0 was released on 22 August 2023; the README still describes the spec as a draft. Listed as an OpenSSF project; CC0 1.0.
OpenVEX
OpenVEX answers the question a scanner cannot: is this product actually exploitable through this vulnerability? A supplier publishes VEX statements, and a consumer’s scanner uses them to suppress findings for components that are patched, absent or unreachable.
- The statement - Each statement joins a product, a vulnerability and a status:
not_affected,affected,fixedorunder_investigation. - Justify the negative - A
not_affectedstatement must carry either a status justification from a fixed set or a free-text impact statement, and the spec discourages relying on the free text in automation. - SBOM-agnostic - Several SBOM formats can embed VEX; OpenVEX is a single format meant to work with any of them, or without one.
- Attestable - A companion document describes wrapping OpenVEX documents in attestations.
- Draft, stable in practice - v0.2.0 is the current release; the README states no large changes are anticipated. CC0 1.0.
Where it sits. OpenVEX is the exploitability layer over an SBOM in SPDX or CycloneDX, complementing vulnerability records in OSV. Its attestations fit the in-toto and SLSA supply-chain model, and a project can point to it from OpenSSF Security Insights.
