Use VEX without losing vulnerability evidence

An SBOM states component presence under its declared scope. A vulnerability match connects a component to an advisory. VEX supplies a product-specific assessment of that vulnerability's impact. These are different records. A not_affected statement does not mean the component was absent from the inventory or that the advisory is false. It means the issuer asserts a particular product is not affected, with a reason whose validity depends on scope and evidence.

OpenVEX provides the statuses affected, not_affected, fixed and under_investigation, and requires a not_affected statement to carry a justification label or an impact statement. Its repository describes the specification as draft; the example here pins the v0.2.0 context and should not be described as a final universal standard. A consumer must know the issuer it trusts and what product identifiers mean. A claim about one product version, platform or feature configuration does not automatically apply to another merely because they share a component name.

Suppliers publish VEX in three formats. CSAF 2.0, an OASIS Standard also published as ISO/IEC 20153:2025, has a VEX profile used in vendor security advisories; CSAF 2.1 is still a committee draft. CycloneDX carries VEX in its vulnerabilities array, either inside an SBOM or as a separate document. The four states line up, but the justification vocabularies differ: OpenVEX and CSAF share five labels, while CycloneDX has nine of its own. Only two map exactly, vulnerable_code_not_present to code_not_present and vulnerable_code_not_in_execute_path to code_not_reachable, so keep the original label when you convert.

The fictional Larch 5.0 includes codec 2.4, but its compiled build excludes the vulnerable legacy decoder. Evidence E17 identifies the exact product digest and symbol/call analysis supporting that exclusion. A defensible not_affected statement binds the product version, vulnerability and justification, with an impact explanation that a reviewer can challenge. Record the evidence reference and limitations outside or alongside the exchange document as appropriate to the chosen format.

The distinction between vulnerable code absent and vulnerable code unreachable matters. The former claims the relevant code is not in the artifact; the latter claims it cannot execute through the product's paths. A disabled default option is weaker if customers can turn it on. The illustrative document below uses vulnerable_code_not_present because the fixture explicitly supplies compiled exclusion evidence. If that evidence were missing, under_investigation would be the honest state. Never select a convenient justification merely to silence a scanner.

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://security.example/vex/larch-5-adv8",
  "author": "https://security.example/larch-team",
  "timestamp": "2026-10-07T12:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": {
        "name": "ADV-8-FICTIONAL"
      },
      "products": [
        {
          "@id": "pkg:generic/larch@5.0.0"
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "For artifact L50 only, build evidence E17 shows legacy decoder excluded; no claim for plugins or L51."
    }
  ]
}

A consumer should authenticate the issuer, match the product identity and vulnerability, inspect the stated rationale and reconcile contradictory local evidence. A signed supplier statement can still be out of scope or stale. Maintain a local acceptance policy that defines when VEX suppresses an alert, when it only changes priority and when further review is required; /domains/supply-chain/dependencies/evidence-based-triage/ routes each finding to one such outcome. The underlying detection should remain recoverable, including the original component identity and advisory data.

In the fixture, the issuer is trusted for Larch, but the deployed product is L51, whose build now includes the decoder. The previous L50 statement cannot suppress L51's finding. A new statement claiming all Larch 5.x products are not affected conflicts with E18 and must be investigated even if its signature verifies. Timestamps and version numbers help sequence statements; the most recently received document is not necessarily the newest authoritative revision. Consumers need a policy for supersession and rollback of incorrect assertions.

Scanners match OpenVEX statements by package URL, so the purl rules in /domains/supply-chain/sbom/formats-and-identifiers/ decide what a statement covers. Name the product as the image, bound to its digest, and the package the statement is about as a subcomponent. The script below writes such a statement with vexctl and applies it with Trivy and Grype. Tested on the alpine:3.22.4 image, CVE-2026-14456 was reported for both libcrypto3 and libssl3; with the statement, both scanners suppressed only the libcrypto3 finding and still reported libssl3. A statement that named the alpine:3.22.6 digest instead suppressed nothing in the same scan.

The near miss is the product identifier. When the product purl had no digest, pkg:oci/alpine?repository_url=..., both scanners suppressed the finding as well, because a purl without a version matches every version of the image. That is the broad suppression the next section warns against. --show-suppressed keeps suppressed findings visible with the statement that suppressed them. Trivy applies CycloneDX VEX only when scanning an SBOM, matching components by BOM-Link rather than by purl.

# Product: the released image by digest. Subcomponent: the package the statement is about.
PRODUCT="pkg:oci/cedar@${DIGEST}?repository_url=ghcr.io%2Facme%2Fcedar"
vexctl create --author "Acme Product Security" \
  --product "$PRODUCT" --subcomponents "pkg:apk/alpine/libcrypto3@3.5.6-r0" \
  --vuln CVE-2026-14456 --status not_affected \
  --justification vulnerable_code_not_in_execute_path \
  --impact-statement "Call-graph evidence E31: Cedar never reaches the affected code." \
  --file cedar-2.3.openvex.json

# Consumers apply it; every other package and vulnerability is still reported
trivy image --vex cedar-2.3.openvex.json --show-suppressed "ghcr.io/acme/cedar@$DIGEST"
grype "ghcr.io/acme/cedar@$DIGEST" --vex cedar-2.3.openvex.json --show-suppressed

A VEX decision should name reopening triggers: product digest changes, affected code or feature becomes available, advisory scope changes, issuer trust is withdrawn, or local evidence contradicts the rationale. For not_affected due to code absence, a build change enabling that code is decisive. For a fixed statement, verify the actual patched product rather than accepting a future release announcement. Uncertainty should produce review, not silent permanent suppression.

There is an operational tradeoff between reducing noise and preserving accountability. Broad wildcard suppression is easy to operate but can hide real exposure after a configuration change, and a product purl without a version is such a wildcard. Very narrow artifact-specific statements cost more to maintain but can be joined to precise release evidence. Use the granularity required by the claim and automate re-evaluation on relevant changes. The exercise is fully self-contained: the JSON is illustrative VEX data, the evidence is fictional, and no scanner or production suppression is changed.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OpenVEX specification. v0.2.0 (draft).
2. CycloneDX specification overview, version 1.7. Version 1.7 (October 2025).
3. OSV: vulnerability data and package queries
4. OASIS: Common Security Advisory Framework Version 2.0. OASIS Standard, 18 November 2022.
5. CycloneDX: VEX capabilities
6. Trivy: applying VEX from a local file
7. Grype: vulnerability scanner (VEX support)
8. vexctl
9. CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX). 21 April 2023.

Reference information

Tags

SBOMVEX and vulnerability statusVulnerability managementVulnerability disclosure

SDLC phase

ReleaseMaintenance

Role

AppSec engineers

Download this guide as Markdown

Continue exploring