OpenVEX

OpenVEX is a minimal, embeddable, machine-readable implementation of VEX — Vulnerability Exploitability eXchange — stewarded within the OpenSSF. Where an SBOM or CBOM tells you what components a product contains, and a scanner tells you which of those components carry known vulnerabilities, VEX answers the question that actually drives triage: is this specific product genuinely affected by this specific vulnerability, and if not, why not? A VEX document is an assertion made by a producer who knows how the component is used, expressed compactly enough to travel alongside a release.

Why it matters

Inventory and scanning tools are tuned to over-report: they flag a vulnerable component wherever it appears, whether or not the vulnerable code path is ever reached. The result is a backlog of findings that buries the few that matter. VEX lets the party who understands the product state exploitability with a justification, so downstream consumers spend remediation effort on real exposure rather than noise. For post-quantum work this is decisive — a cryptographic inventory will surface quantum-vulnerable algorithms across a large estate, and most instances are not equally urgent.

What OpenVEX asserts

VEX defines four status values, each attached to a product-and-vulnerability pair. A not_affected assertion additionally carries a justification explaining why the vulnerable component does not create real exposure — for example, that it is present in the build but not in the execution path:

• **not_affected** — the product is not exploitable by this vulnerability; the assertion must include a justification (e.g. the component is present but never called, or the vulnerable configuration is not enabled).
• **affected** — the product is exploitable; downstream consumers should act, and the statement may carry remediation guidance.
• **fixed** — a released version contains a remediation for the vulnerability.
• **under_investigation** — the producer has not yet determined status; a placeholder that stops consumers from guessing.

In a post-quantum program, OpenVEX becomes the exploitability layer over the inventory. As CBOM enumerates cryptographic assets and SARIF carries the code-scanning findings that flag quantum-vulnerable algorithms, OpenVEX communicates which of those findings are genuinely relevant in a given product context. An RSA usage that only protects an ephemeral, short-lived session key is a different risk from the same algorithm protecting long-lived secrets — VEX is where that distinction is recorded and passed downstream, focusing migration effort where data lifetime makes it count.

How quantakrypto helps

OpenVEX is only as good as the analysis it encodes, and quantum exploitability is exactly the kind of judgment that is easy to get wrong under time pressure. We build the cryptographic inventory and CBOM that OpenVEX statements reference, then stress-test the justifications behind each not_affected claim against data-lifetime and harvest-now-decrypt-later reasoning (audit) — so the exploitability assertions you publish hold up, and your migration roadmap is driven by real exposure rather than raw scanner counts.