OpenVEX: the minimal, embeddable VEX format

An SBOM lists every component in a product; a vulnerability scanner matching that component list against the NVD or OSV will flag every CVE affecting every listed library version — most of which never execute in a way that's actually reachable or exploitable in that product. A VEX (Vulnerability Exploitability eXchange) document is the manufacturer's own machine-readable statement of which of those flagged CVEs actually matter, separating signal from noise for a downstream customer or regulator running automated SBOM-to-vulnerability matching. The Cyber Resilience Act's CRA vulnerability-handling obligations and most large-customer SBOM intake programs expect exactly this kind of exploitability triage, not a raw, unfiltered CVE list.

Six required top-level fields, per the official OPENVEX-SPEC.md: @context (the OpenVEX JSON-LD context URL), @id (a document identifier that must be an IRI compliant with RFC3987 — OpenVEX offers a public namespace at https://openvex.dev/docs/[name]), author, timestamp, version (incremented on any content change), and statements — the array of per-vulnerability assessments, each naming a product, a vulnerability identifier, and a status.

Every OpenVEX statement carries one of four status values: not_affected (no action needed), affected (remediation recommended), fixed (a fix ships in this version), or under_investigation (not yet determined). A not_affected statement must include either a free-form impact_statement or one of five machine-readable justification labels defined by the spec: component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, and inline_mitigations_already_exist — the same justification vocabulary CISA's Minimum Requirements document defines, so a scanner or customer intake tool can parse the reason programmatically instead of relying on prose.

No — CISA's own VEX guidance names four formats in current use without mandating any one of them. The practical differences are weight and workflow fit. CSAF 2.0 VEX (see our CSAF/VEX guide) is built for PSIRTs that already run a full CSAF advisory-publishing pipeline with discoverable provider metadata. CycloneDX VEX (see our CycloneDX VEX guide) fits teams whose tooling already emits CycloneDX SBOMs, either embedding VEX statements in the same document or publishing them standalone via bom-link. OpenVEX is the lightest of the three: a single small JSON-LD file with no encapsulating SBOM and no advisory-publishing infrastructure required, which is why it shows up as the default output format in several open-source vulnerability-triage and SBOM-generation tools, including the project's own vexctl CLI and the openvex/go-vex library used to consume and transform VEX data from other formats.

OpenVEX only states exploitability — it assumes a product and component identifiers already exist, from an SBOM or otherwise. For firmware where no source-accurate SBOM exists because the binary was built by a third-party vendor, the harder problem is generating a trustworthy component list in the first place (see our firmware SBOM guide). SoftWSP's firmware security assessments extract the actual open-source component inventory from a firmware binary and flag which flagged CVEs are reachable in the shipped build, producing the kind of evidence a not_affected OpenVEX justification needs to be defensible rather than asserted. See PSIRT services for how VEX publishing fits into an ongoing disclosure workflow.

This guide is based on the official OPENVEX-SPEC.md in the openvex/spec GitHub repository, the OpenSSF OpenVEX project page, and CISA's April 2023 Minimum Requirements for Vulnerability Exploitability eXchange document, all read directly for this guide. The OpenVEX specification is actively versioned (v0.2.0 at the time of writing, which introduced an expanded product and vulnerability field structure); check the spec repository for the current version before implementing against a specific field layout.