VEX Explained: What a "Not Affected" Statement Means and How to Read One

VEX, short for Vulnerability Exploitability eXchange, is a way for a supplier (or another party) to say, in a structured document, whether a specific product is affected by a specific vulnerability. A VEX statement about a library you find in your scanner output answers the question the scanner cannot: “this component is present, but can the flaw actually be reached?” This article explains the vocabulary CISA defined, shows how two formats (OpenVEX and CSAF) express it, and sets out how to evaluate a “not affected” claim before you let it close a ticket.

We read CISA’s June 2022 status-justification guidance, the OpenVEX specification, the CSAF 2.0 standard and parts of Trivy’s documentation on October 13, 2026. We did not write or consume a VEX document in a live pipeline for this article, so it is research-based explanation, not hands-on testing.

The short answer

• A VEX statement ties one product to one vulnerability and gives a status.
• CISA’s guidance says the status must be one of NOT AFFECTED, AFFECTED, FIXED or UNDER INVESTIGATION.
• A NOT AFFECTED status can carry a justification from a fixed list of five, so a tool can act on it.
• It is a claim by whoever wrote the document. CISA says the consumer “may choose to accept it or not.”

What a VEX document must contain

CISA’s guidance states that VEX documents must contain four things: VEX metadata, product details, vulnerability details and product status. CISA also published a separate “Minimum Requirements for VEX” document (the CISA page is dated April 21, 2023). We could not download that PDF (CISA’s server returned “Access Denied” to our request), so we rely on the OpenVEX specification, which says it aims to meet those minimum requirements, and on the CISA status-justification guidance quoted above.

The four statuses

Sources: CISA, VEX Status Justifications (June 2022); OpenVEX specification; CSAF 2.0 standard. The column pairing is our mapping of equivalent concepts; each source defines its own values. CSAF defines further categories (for example first_affected and last_affected) that have no direct CISA counterpart.

The OpenVEX specification uses a hypothetical timeline to show why the statuses exist. A vendor learns of a new CVE and publishes under_investigation; later it finds the product affected and publishes affected with mitigation advice; when it ships a patch it publishes fixed. Without that sequence, the spec notes, a scanner user “will simply get a third party alert with no details on how the status is evolving,” and the alert becomes a false positive once the product is patched.

The five “not affected” justifications

A justification is the machine-readable reason behind a NOT AFFECTED claim. CISA lists five. The definitions below paraphrase CISA’s June 2022 document; the examples in the last column are CISA’s.

Two caveats from CISA’s own text are easy to miss:

1. For vulnerable_code_not_in_execute_path, CISA warns that “a single path of execution should not be assumed since the attacker may be able to divert the path of execution.”
2. For inline_mitigations_already_exist, CISA notes that mitigations are effective “only in the scenario where the threat model of the software allows it,” and a mitigation that works in one product may not in another. The OpenVEX specification adds that this justification “could be difficult to prove conclusively.”

CISA also distinguishes the last two. With vulnerable_code_cannot_be_controlled_by_adversary, nothing the attacker does can reach the vulnerable code in a way that triggers it. With inline_mitigations_already_exist, the attacker can influence execution, but another control blocks the attack. Both, CISA says, “rely on an expert analysis of the structure of the code.”

How the formats express it

OpenVEX

OpenVEX is a JSON format. Per its specification, a document requires @context, @id, author, timestamp, version and statements. Each statement needs a vulnerability, a status and at least one product (these can be inherited from the document in some cases, and the specification says a document with incomplete statements is not valid). For not_affected, the statement must include either a justification or an impact_statement, which is free text. The specification says free-text impact statements are “highly discouraged for automated systems.” For affected, it must include an action_statement describing how to remediate or mitigate.

A minimal not-affected statement looks like this. Everything below is an invented placeholder: the CVE number, the product identifier and the author are not real.

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-0001",
  "author": "Example Product Security Team",
  "timestamp": "2026-10-13T06:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2026-00000" },
      "products": [{ "@id": "pkg:oci/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    }
  ]
}

The version field, the specification says, must be incremented when any content of the document changes, which is how a supplier moves from under_investigation to fixed over time.

CSAF 2.0

CSAF (Common Security Advisory Framework) is an OASIS Standard, approved November 18, 2022, with an errata release dated January 26, 2024 that changes only an aggregator schema. Its Profile 5: VEX requires a product tree, a list of vulnerabilities, and at least one of the fixed, known_affected, known_not_affected or under_investigation product-status lists. It also sets two content rules:

• For each product in known_not_affected, an impact statement must exist, either as a machine-readable flag or as a human-readable impact entry in threats.
• For each product in known_affected, product-specific action information must be given in remediations; the categories no_fix_planned and none_available are permitted.

CSAF’s flag labels are the same five justification values as CISA’s list.

Reading a VEX statement critically

A scanner that supports VEX can hide findings based on these documents. That is the point, and also the risk. These are our practical checks, not requirements from CISA, OpenVEX or OASIS:

1. Match the product exactly. Check that the product identifier and version in the statement are the ones you deploy, not a sibling image or a different build.
2. Check who signed it. OpenVEX says the author’s identity “SHOULD be cryptographically associated with the signature of the VEX document.” An unsigned file fetched from an arbitrary location is a weaker basis than a signed statement from the supplier.
3. Prefer machine-readable justifications. A bare not_affected with free text gives your tooling, and a future auditor, little to evaluate.
4. Weigh the justification type. component_not_present is something you can verify against your own SBOM. inline_mitigations_already_exist relies on the supplier’s threat model, which is hard to check from outside.
5. Treat known-exploited vulnerabilities with extra care. If a vulnerability is on CISA’s Known Exploited Vulnerabilities list, a wrong “not affected” is expensive. Our article on CVSS, EPSS and KEV covers how to use that signal.
6. Keep the audit trail. Record which VEX document suppressed which finding, and re-evaluate when the document’s version changes.

CISA’s guidance also notes that VEX statements cover known vulnerabilities and that attackers often chain flaws; new vulnerabilities may emerge that do affect a product. A “not affected” for one CVE says nothing about the next.

Using VEX with scanners

Tool support varies. As one example, Trivy’s documentation says VEX can be used “to filter vulnerabilities based on their status,” and shows the --vex option with four sources: a VEX repository, a local file, a VEX attestation stored in an OCI registry, or VEX files referenced in an SBOM. That page was marked “EXPERIMENTAL” when we read it and warned that the feature “might change without preserving backwards compatibility.” We did not test Trivy or any other scanner’s VEX handling, and we did not check which formats each scanner accepts, so confirm support for your chosen format and version before relying on it.

Where VEX fits

• With an SBOM: the SBOM lists components; VEX says which vulnerabilities in them matter. See our article on the 2026 SBOM minimum elements.
• With provenance: signing and provenance tell you who built an artifact and how, not whether a given CVE affects it. See SLSA build levels and provenance attestations.
• With image scanning: VEX is one way to reduce noise from scanners; see what container image scanning still misses.

Limits of this article

We could not read CISA’s “Minimum Requirements for VEX” PDF (access denied). The CISA status-justification document is from June 2022 and its own text says it is not exhaustive and that CISA may add justifications later; we did not look for later revisions. We did not review the CycloneDX VEX specification, or the details of any scanner’s VEX support beyond the Trivy page above. The OpenVEX specification page is titled v0.2.0 but also contains an older revision-table entry using a different version number, so check the version your tools implement.

Sources and verification

Checked on October 13, 2026.

Supply ChainVulnerability Management