CycloneDX VEX: how the analysis state and justification fields work

Every vulnerability entry in a CycloneDX document can carry an analysis object with up to three fields. state records the current assessment: resolved, resolved_with_pedigree, exploitable, in_triage, false_positive, or not_affected. justification is required whenever state is not_affected, and must be one of nine specific reasons — code_not_present, code_not_reachable, requires_configuration, requires_dependency, requires_environment, protected_by_compiler, protected_at_runtime, protected_at_perimeter, or protected_by_mitigating_control. response is a separate array recording vendor action: can_not_fix, rollback, update, will_not_fix, or workaround_available. A typical "we checked, it doesn't apply" statement looks like {"state": "not_affected", "justification": "code_not_reachable"} — a specific, falsifiable claim, not a generic risk label.

VEX support shipped in CycloneDX v1.4, released January 2022 — the version CycloneDX's own history page credits as "the first specification to introduce vulnerability sharing and transparency, including Vulnerability Disclosure Reports (VDR) and Vulnerability Exploitability eXchange (VEX)." That release also introduced the bom-link reference type, which is what lets a VEX document point at components defined in a separate SBOM file rather than repeating them. Versions 1.5 and 1.6 broadened the surrounding vulnerabilities data model and added unrelated capabilities (CBOM for cryptographic assets, CDXA for attestations), but the analysis object's enum values covered above have been stable since 1.4 — a VEX statement written for a 1.4 SBOM reads the same way against a 1.6 one.

Both are valid. Embedded VEX is a vulnerabilities array inside the same CycloneDX document that also lists the product's components — convenient when one team produces both together. Standalone VEX is a second CycloneDX document containing only the vulnerabilities array, with each entry's affects field pointing at a component defined in a separately published BOM via a bom-link URN. Standalone VEX is the better fit when a PSIRT publishes updated exploitability assessments on its own cadence, independent of when a new SBOM is generated from a build. CISA's own guidance on VEX implementations lists CycloneDX as one of four formats in current use — alongside the CSAF 2.0 VEX profile, OpenVEX and SPDX 3.0 — without mandating any one of them; see our CSAF 2.0 and VEX guide and CycloneDX vs SPDX guide for how the four compare.

Yes — the enum values are consumed programmatically, not just displayed. Trivy's own documentation describes VEX as a way to "filter detected vulnerabilities," supporting VEX supplied as a local file, an OCI registry attestation, a remote VEX repository, or a reference embedded in the SBOM itself; a component whose CycloneDX VEX entry carries not_affected with a valid justification is excluded from Trivy's reported findings rather than merely annotated. Dependency-Track, the most widely deployed open-source SBOM analysis platform, similarly ingests analysis.state to re-triage findings automatically rather than requiring a human to re-review every CVE on every rebuild. That is the practical payoff of a structured enum over free-text notes: a scanner can act on not_affected + code_not_reachable without a human reading a sentence first.

SoftWSP generates firmware SBOMs directly from binary images and can produce the matching CycloneDX VEX analysis — state, justification and response — for vulnerabilities its own scans flag, so a device maker's downstream customers and scanners stop re-flagging CVEs that do not actually apply to the shipped firmware. See PSIRT as a service for how that fits into an ongoing vulnerability-response process.

This guide is based on CycloneDX's own capability and history pages, the CycloneDX Python library's published enum definitions (which mirror the JSON/XML schema), CISA's Minimum Requirements for VEX document, and Trivy's published VEX documentation, all read directly for this guide. Enum values were cross-checked against the CycloneDX Python library's source rather than taken from a single secondary summary; verify against the current CycloneDX JSON schema at github.com/CycloneDX/specification before relying on a specific field name in tooling you build.