What Is a VEX Statement, and How Do Auditors Use It?

The short answer

A VEX (Vulnerability Exploitability eXchange) statement is a machine-readable assertion about the status of a product with respect to one vulnerability. It gives exactly one of four statuses: not_affected, affected, fixed or under_investigation. A not_affected statement carries a justification or an impact statement explaining why, and an affected statement carries an action statement saying what to do.

Auditors use VEX as evidence that a scanner finding was assessed rather than ignored. They accept it when the author is identifiable, the statement is current, the justification matches the deployment, and someone will update it when things change. They do not accept it as proof that an end-of-life component is supported, which is a separate question. This article is general information, not legal or audit advice.

The minimum elements, according to CISA

In April 2023 CISA published Minimum Requirements for Vulnerability Exploitability eXchange (VEX), drafted by a community of industry and government experts. It defines the elements independently of any format. CISA notes that the document does not represent official CISA policy and does not mandate compliance, but most VEX tooling follows it.

Product IDs should reuse SBOM identifiers, and the document recommends a supplier, product and version construct. A statement can also name a subcomponent. The common case is a statement that the subcomponent is affected while the product containing it is not.

The four statuses

The five justification codes

The OpenVEX specification adds a caution next to the last two: both "could be difficult to prove conclusively". Auditors read them the same way and ask for more evidence when they appear.

The formats: OpenVEX, CSAF and CycloneDX

CISA names three formats that can contain or generate VEX.

• OpenVEX (specification v0.2.0) is the smallest. It is JSON-LD with a document wrapper and a list of statements using the four CISA status labels and the five justifications. For not_affected it requires either a justification or an impact statement, and it discourages relying on the free-text impact statement in automated systems.
• CSAF 2.0, the OASIS advisory standard, has a VEX profile (section 4.5). Products are listed under known_not_affected, known_affected, fixed or under_investigation. Every known_not_affected product needs an impact statement, as a machine-readable flag or as a threat of category impact, and every known_affected product needs a remediation. The remediation categories no_fix_planned and none_available are permitted, which is how a supplier says plainly that a vulnerable version will not be fixed.
• CycloneDX records an analysis state on each vulnerability, either inside the SBOM or as a separate document.

How scanners consume VEX

The point of VEX is that the scanner applies it automatically on every run. Trivy accepts VEX through its --vex option in three formats: CycloneDX (for SBOM targets), OpenVEX and CSAF. A finding marked not_affected is no longer reported. Grype supports OpenVEX for filtering and augmenting scan results. CISA's November 2023 guidance, When to Issue VEX Information, adds that scanning tools "should sufficiently validate the accuracy of VEX information, involving human analysts when necessary". A suppressed finding is only as trustworthy as the statement that suppressed it.

Who issues VEX

CISA's guidance lists suppliers, researchers, vulnerability coordinators and other parties, naming auditors and contract software support organizations among the latter. The supplier is the natural author because it knows how the component is used. For open source, the guidance says that where no active maintainers exist, downstream users or community members could provide VEX information, and it adds that "unmaintained software carries a variety of security and development risks beyond the availability of VEX information". That sentence is the end-of-life problem in brief.

What an auditor checks before accepting a VEX statement

1. Who wrote it. The author must be a person or organization, and CISA recommends that the author's identity be cryptographically associated with the document's signature. An unsigned file from an unknown source carries little weight.
2. When. Timestamps for first issue and last update should be compared with the scan date and with changes to the deployment since then.
3. Which product. The product ID should match the SBOM entry and the exact version deployed, not a product family in general.
4. Why. For not_affected, the justification must match evidence the auditor can see: configuration files, build options, network rules.
5. What happens next. An under_investigation status left open for months, or an affected status with no action taken, is a finding in its own right. CISA expects issuers to communicate changes in status.

VEX answers the vulnerability question one CVE at a time. It does not answer whether the component is supported. Controls such as NIST SP 800-53 SA-22 and PCI DSS ask that second question directly; see SA-22 and unsupported components and PCI DSS and EOL software.

Example: a product with ZooKeeper 3.6.4 inside

Suppose a product you buy embeds ZooKeeper 3.6.4, and the scanner reports two CVEs against the jar.

• CVE-2023-44981, an authorization bypass in SASL quorum peer authentication. The ZooKeeper advisory says it only applies when quorum.auth.enableSasl=true, and that quorum peer authentication is not enabled by default. If no server in the ensemble sets it, the supplier can issue not_affected with vulnerable_code_not_in_execute_path and evidence from every server's configuration.
• CVE-2024-23944, information disclosure through persistent watchers because of a missing ACL check. The advisory lists 3.6.0 through 3.7.2 as affected and the fixes as 3.8.4 and 3.9.2. No 3.6 release contains a fix, and no configuration avoids it, so the honest status is affected with an action statement.

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/product-x-2026-10-05",
  "author": "Example Corp product security",
  "timestamp": "2026-10-05T00:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-44981" },
      "products": [{ "@id": "pkg:maven/org.apache.zookeeper/zookeeper@3.6.4" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "quorum.auth.enableSasl is not set on any server."
    },
    {
      "vulnerability": { "name": "CVE-2024-23944" },
      "products": [{ "@id": "pkg:maven/org.apache.zookeeper/zookeeper@3.6.4" }],
      "status": "affected",
      "action_statement": "No upstream 3.6 release fixes this. Replace the jar with a patched 3.6 build or move to 3.8.4 or later."
    }
  ]
}

Once a patched build replaces the jar, the second statement is updated to fixed against the patched build's own product ID, and the document version is incremented. The longer walk-through, including how scanners fingerprint the jar and why a patched build needs its own SBOM entry, is in why your scanner flags embedded ZooKeeper.

Where OSSeva fits

When the honest VEX status is affected and upstream has no release to point to, the action statement needs a real fix behind it. OSSeva Patch ships signed, drop-in builds with backported fixes for community end-of-life lines such as ZooKeeper, so the status can move to fixed. OSSeva Assure adds written attestation for CVEs that do not apply to a given deployment, along with the compliance documentation auditors ask for. The compliance library maps these to SOC 2, PCI DSS, HIPAA and DORA.

Frequently asked questions

Is VEX the same as an SBOM?

No. An SBOM lists the components in a product. VEX states, per vulnerability, whether the product is affected. They are designed to work together, but CISA notes that VEX does not require an SBOM.

Can someone other than the vendor write a VEX statement?

Yes. CISA's guidance lists researchers, coordinators, auditors, service providers and contract software support organizations among possible issuers. The statement carries the author's name, so its weight depends on that author's access to the facts.

Does a not_affected statement close an audit finding?

It closes the vulnerability finding for that CVE if the auditor accepts the evidence. It does not close a finding that the component itself is unsupported.

Which VEX format should we use?

Use one your scanners read. OpenVEX is the lightest to write by hand; CSAF suits suppliers that already publish security advisories; CycloneDX suits teams whose SBOMs are already in CycloneDX.