VEX, Vulnerability Exploitability eXchange, is the force multiplier on top of SBOMs. Without VEX, SBOM-based vulnerability analysis drowns in false positives. With VEX, you can assert that a component is present but not exploitable, suppress the alert, and move on to real issues. By 2026, the two dominant VEX formats are OpenVEX and CycloneDX VEX, and most teams eventually have to pick one to standardize on.
I have implemented both in production environments and advised on the choice for federal and enterprise customers. The spec comparisons you find online are technically correct but miss the operational nuances. Here is the version that accounts for how these formats actually behave in a running program.
What are the actual spec differences in 2026?
OpenVEX is a minimalist spec. A document asserts statements linking a set of products to a set of vulnerabilities with a status: not_affected, affected, fixed, or under_investigation. The core schema is small, the required fields are few, and the entire spec can be grasped in a single reading. Each statement is timestamped and the document has its own timestamp, enabling temporal queries over time.
CycloneDX VEX is an extension of the CycloneDX BOM format. A VEX document is a CycloneDX BOM that carries a vulnerabilities array, where each vulnerability entry includes analysis information: impact, state, response, and detail. CycloneDX VEX supports richer metadata and integrates with the full CycloneDX ecosystem of attestations, formulations, and SBOM types.
The fundamental difference is philosophy. OpenVEX is built to be a standalone document that asserts claims independent of the SBOM. CycloneDX VEX is built to travel with or alongside its SBOM, sharing identifiers and lifecycle. Both are valid designs. The operational consequences differ.
Which format has better tooling support?
Tooling parity has improved a lot since 2024. OpenVEX has vexctl, which is part of the OpenSSF project ecosystem and integrates cleanly with Sigstore for signed VEX documents. The OpenVEX CLI is well-maintained and the format is supported by Trivy, Grype, and most modern vulnerability scanners for consuming and applying VEX.
CycloneDX VEX benefits from the broader CycloneDX tooling ecosystem. Dependency-Track has first-class CycloneDX VEX support, and the CycloneDX reference implementations handle VEX alongside SBOM operations naturally. If you are already committed to CycloneDX for SBOMs, the VEX story is already integrated.
Cross-format conversion works in both directions but is lossy. OpenVEX-to-CycloneDX conversion preserves the core assertions but drops some richer metadata that OpenVEX does not have. CycloneDX-to-OpenVEX conversion drops extensions that OpenVEX cannot express. In practice, pick one format for authoring and use tooling to emit the other for consumers who require it.
How do the temporal models compare?
OpenVEX's temporal model is the cleaner of the two. Every statement carries a timestamp, and documents can be chained using the updates field to supersede earlier statements. This makes it straightforward to answer questions like "what was our VEX position on CVE-X on date Y?" by walking the chain backward.
CycloneDX VEX supports timestamps on vulnerabilities and on the overall BOM, but the pattern for superseding is less standardized. Some teams version their VEX documents manually through CycloneDX BOM versioning. Others treat each document as a snapshot. Both approaches work, but the semantics are less prescribed than OpenVEX.
For teams that care about audit trails and historical accuracy, OpenVEX's explicit update chains are a real advantage. Regulated industries that have to demonstrate what they knew and when they knew it tend to gravitate toward OpenVEX for this reason.
What about signing and attestation?
OpenVEX integrates tightly with Sigstore. The reference implementation assumes that production VEX documents are signed with cosign, and the patterns for keyless signing, attestation creation, and verification are well documented. If your supply chain security stack is already built on Sigstore, OpenVEX slots in naturally.
CycloneDX VEX supports signing through the CycloneDX attestation model and through external mechanisms. You can sign a CycloneDX BOM that carries VEX with Sigstore, with Notary, or with traditional PKI signatures. The flexibility is genuine, but the opinionated path is less established than OpenVEX plus Sigstore.
For federal and heavily regulated environments, OpenVEX plus Sigstore is increasingly the default. For enterprise environments that already standardize on CycloneDX end-to-end, CycloneDX VEX with CycloneDX-native signing is the lower-friction choice.
Which should you pick in 2026?
Pick OpenVEX if you want a minimalist, focused spec that does one thing well, if Sigstore is already part of your stack, if you need strong audit trails with explicit update chains, or if you publish VEX to a broad external audience that may not standardize on CycloneDX.
Pick CycloneDX VEX if you have already standardized on CycloneDX for SBOMs, if you want richer metadata fields for internal analysis workflows, if you use Dependency-Track or other CycloneDX-native tooling as your primary vulnerability management platform, or if your consumers prefer a single unified document that combines SBOM and VEX information.
The choice is less consequential than the choice to publish VEX at all. Teams that publish either format consistently outperform teams that publish neither. If you are torn, pick the one that matches your existing tooling and move on.
How do you scale VEX authoring?
Manual VEX authoring does not scale past a few dozen components. By 100 components with public CVEs, you need automation. The pattern that works is to classify vulnerabilities by reachability and then generate default VEX statements for the unreachable ones, with human review before signing.
Reachability classification is where the leverage is. If your static analysis determines that a vulnerable function in a dependency is never called from your application entry points, you have strong evidence that the CVE is not exploitable in your context. That evidence justifies a not_affected VEX statement with a justification of vulnerable_code_not_in_execute_path. This is a defensible position that regulators and customers accept.
Pair reachability classification with VEX generation and you eliminate 60 to 80 percent of the VEX authoring workload. The remaining statements, the ones where reachability analysis is ambiguous or where the CVE requires a product-specific analysis, are where your security engineers should be spending their time.
How Safeguard.sh Helps
Safeguard.sh generates and maintains VEX documents in both OpenVEX and CycloneDX VEX formats automatically, so you do not have to pick a lane before your tooling is ready. Our reachability engine classifies 60 to 80 percent of CVE noise as unreachable and drafts VEX statements with proper justifications, which Griffin AI reviews against your policy and signs through Sigstore integration. With 100-level transitive dependency depth, SBOM ingestion, TPRM, and container self-healing built in, Safeguard.sh keeps your VEX corpus synchronized with your fleet as dependencies evolve.