Teams sometimes stall on which VEX format to adopt as though it were a one-way door. It isn't. The three common formats say the same thing in different shapes, they interoperate, and — the part worth internalising — the format is the least important decision in the whole VEX story.
Same job, three shapes
Every VEX format carries the same core statement: a product, a vulnerability, and one of four statuses — not_affected, affected, fixed, under_investigation — with a justification and optional detail. What differs is the container and the ecosystem around it.
CycloneDX VEX
From OWASP, and built for exactly this problem. Its distinguishing feature is that VEX can live in the same document as the SBOM, so your inventory and your applicability statements travel together. If you already generate CycloneDX SBOMs — a common CRA default — carrying VEX in the same format keeps everything in one lineage.
OpenVEX
A deliberately minimal, standalone specification. An OpenVEX document is a small, self-contained statement that's easy to produce, sign and pass around independently of any SBOM. It suits pipelines that want VEX as its own lightweight artifact rather than embedded.
CSAF VEX
CSAF (Common Security Advisory Framework) is an OASIS standard for machine-readable security advisories; its VEX profile expresses VEX within a full advisory document. If you publish structured advisories — or need to — CSAF lets your VEX and your advisories share one format. It's heavier than OpenVEX and richer for advisory workflows.
How to choose
| Format | Best when |
|---|---|
| CycloneDX VEX | You want VEX alongside the SBOM in one document; you already use CycloneDX. |
| OpenVEX | You want a minimal, standalone, easily-signed statement. |
| CSAF VEX | You publish machine-readable advisories and want VEX in the same framework. |
They convert between each other cleanly enough that producing one and exporting another on request is a normal pattern. Picking "wrong" is cheap to undo.
What actually matters
The format is the wrapper. Whether a not_affected is backed by evidence or just asserted is the content — and it's what a regulator will actually test.All three formats will happily carry a status a human typed in on a hunch. None of them makes that status defensible. The decision that matters isn't CycloneDX-versus-OpenVEX; it's whether a reachability trace and an exploitation attempt sit behind the status — see evidence-backed VEX. Whichever format you emit, emit it with something behind it.
Frequently asked
CycloneDX VEX or OpenVEX — which should I use?
Either satisfies the CRA. CycloneDX VEX suits teams who want VEX embedded alongside their SBOM in one document; OpenVEX suits a lightweight, standalone statement. Many teams produce CycloneDX and can export the others on request. Pick by your workflow, not by regulatory necessity.
What is CSAF VEX?
CSAF (Common Security Advisory Framework) is an OASIS standard for machine-readable security advisories; its VEX profile expresses VEX statements within that advisory format. It suits organisations already publishing CSAF advisories, and is a strong fit for structured advisory workflows.
Does the CRA require a specific VEX format?
No. The CRA does not name VEX or any single format. It requires documented, machine-readable vulnerability handling and advisories; any of the common VEX formats meets that in a standard way.