How VEX Turns an SBOM From a Parts List Into Testable Audit Evidence

Key Takeaways

• A Vulnerability Exploitability eXchange (VEX) statement gives one status for one vulnerability across one or more products.
• A VEX statement is its author’s claim, so an auditor checks who issued it, whether it has changed, and what analysis backs the status.
• The U.S. Cybersecurity and Infrastructure Security Agency (CISA) defines four VEX statuses, and a statement with the not affected status must say why, with a justification value or a written impact statement.
• Several formats can carry VEX, and CycloneDX uses its own status and justification labels, so its documents may need translating to CISA’s names.
• When no upstream fix exists, a supplier can issue not affected with a justification, affected with an action statement, or fixed once a patched version is in the build.

A software bill of materials (SBOM) tells you what’s inside a release, but not which of the vulnerabilities a scanner matches to those components actually apply to your product. VEX (Vulnerability Exploitability eXchange) fills that gap: it’s how a supplier or third party states whether a known vulnerability affects a software product.

CISA’s VEX guidance treats each statement as its author’s claim. How much a reader can rely on one depends on who issued it, how it’s signed, and what evidence the auditor’s compliance framework accepts. In this article, “testable audit evidence” means a claim an auditor can check against the analysis behind it. A VEX statement isn’t proof on its own.

What Is Vulnerability Exploitability eXchange

As CISA describes it, VEX is a way to indicate the status of a software product or component with respect to a vulnerability. In CISA’s Minimum Requirements for VEX, version 1.0.0 from April 2023, a VEX document is a container for one or more statements. Each statement conveys a single status for a single vulnerability across one or more products.

VEX is designed to integrate with SBOMs, vulnerability databases, and security advisories, but CISA says it doesn’t require any of them. CISA’s April 2022 use cases document describes a VEX document as itself a form of security advisory.

VEX is a data format. It isn’t a law, and CISA’s minimum requirements say they aren’t official CISA policy and don’t impose compliance. The 2026 SBOM minimum elements from CISA and its partners don’t include VEX either.

A supplier or a third party can author a VEX document. The author has to be identified as an individual or an organization and is responsible for the content.

What VEX Does and Doesn’t Prove to an Auditor

Because the author answers for a VEX document’s content, everything in it is a claim by that author. CISA’s guidance says documents and statements should be signed, with the author’s identity cryptographically tied to the signature. It also requires a higher document version whenever content changes, plus first-issued and last-updated timestamps. Those let an auditor ask who made the claim, when, and whether it has changed since.

From CISA’s Use Cases Document: The April 2022 publication says VEX statuses aren’t meant to end a discussion. They exist to help consumers make informed decisions, so a reader can question a status instead of treating it as final.

CISA and its partners published the 2026 Minimum Elements for a Software Bill of Materials on July 29, 2026. Its section “Correlating SBOM With Security Advisories” covers VEX and the Common Security Advisory Framework (CSAF). It says a status update helps avoid unnecessary effort when a trusted source judges that potential risk doesn’t translate to actual risk. That benefit depends on trusting the source, so the issuer’s identity decides whether a reader can act on a status.

Pairing VEX with an SBOM also requires a complete SBOM. The 2026 document’s Coverage element says a recipient should be able to conclude a newly reported vulnerability doesn’t affect them if the SBOM doesn’t list the component, and that conclusion is only safe if the SBOM lists everything. The same document places checking an SBOM’s accuracy, coverage, and completeness outside its minimum elements, so a VEX statement that relies on an SBOM can inherit whatever the SBOM gets wrong.

A VEX statement also speaks only to vulnerabilities in a component, so it says nothing about whether the package you pulled was tampered with or is malicious. If your product is built on open source packages, your VEX statements are only as reliable as your record of what went into each build.

Some reviewers also ask for the analysis behind each finding. For medical devices, the U.S. Food and Drug Administration’s (FDA) nonbinding February 2026 premarket cybersecurity guidance asks manufacturers for a safety and security risk assessment of each known vulnerability in their components, plus the risk controls that address it. A status with no analysis behind it gives such a reviewer little to test, so the fields that carry the reasoning, covered next, matter most.

The Four Statuses and What a Not Affected Statement Must Explain

CISA’s minimum requirements, version 1.0.0, say every statement must use one of four statuses. Two of them carry a required detail, and the table shows which.

The April 2022 use cases document asks for an impact statement on every not affected statement. The April 2023 minimum requirements let a justification take its place.

The minimum requirements define five justification values, and the last one is stricter than its name suggests:

• Component not present applies when the vulnerable subcomponent isn’t included in the product.
• Vulnerable code not present covers a component that’s there while the vulnerable code isn’t, typically because the build configuration excludes it.
• Vulnerable code not in execute path fits code that can’t run given how the product uses it.
• Vulnerable code cannot be controlled by adversary describes code that’s present and used, but that an attacker can’t steer to exploit the vulnerability.
• Inline mitigations already exist requires built-in protections that an attacker can’t subvert, that a user can’t configure or disable, and that fully prevent exploitation by known attack vectors.

Each value usually calls for a different kind of backing: an SBOM or other composition record, a build configuration, a call-path analysis, an input-handling analysis, or the mitigation itself. CISA’s requirements let a statement carry status notes on how the status was determined, so record that backing there or next to the statement. The justification value alone won’t tell a reviewer why you made the claim.

Match the status to the work you’ve done. Affected tells readers the product is exposed and that the author recommends actions. Don’t use it for a finding you haven’t analyzed: while the analysis is underway, mark the finding under investigation. CISA expects that status to change when the investigation concludes, so a statement that keeps it with no update tells a reviewer the analysis may have stalled.

Formats and Specifications That Can Carry VEX

CISA’s 2023 minimum requirements name three formats that can contain or be used to generate VEX documents: CSAF, CycloneDX, and OpenVEX. The requirements define their data elements independent of any format. The Software Package Data Exchange (SPDX), which CISA’s list doesn’t name, can also carry all four statuses: its Security profile in version 3.0.1 has a VEX relationship class for each. Each format’s VEX specification defines its own fields, and versions and standing differ.

The formats don’t all use CISA’s labels. OpenVEX’s project documentation says CycloneDX VEX defines its own status and justification labels, so documents may need translating to match the CISA names. This article uses CISA’s names throughout. Pick the format your toolchain and your customers already handle, since the VEX data elements don’t depend on it.

When No Upstream Fix Exists

What you have to prove depends on whether a fix exists. If upstream has published one and you ship it, the statement can say fixed and name the product versions that contain it. A fixed statement usually needs no analysis of whether the vulnerable code can run, because it points at a remediation. Its backing is typically the patched artifact and a version record. The statement is still the issuer’s claim, so exact versions matter. CISA’s use cases document recommends listing versions explicitly where possible, because complex version ranges are harder to parse.

Without a fix, you have three routes. You can analyze the finding and issue not affected with a justification, issue affected with an action statement, or get a patched version into your build and issue fixed. The first route costs analysis that goes stale as code changes. CISA’s use cases document warns that a statement about all versions also covers future versions, and can include versions already at end of life. Its example is a claim that a Rust program can’t be affected by a Java vulnerability, which turns misleading if a later version adopts Java and nobody updates the document. The second route has its own constraint. If the analysis shows your product is exposed, the action statement can’t tell readers to upgrade to a fixed release that doesn’t exist. It should describe a mitigation or another step readers can take.

The third route is the one unmaintained components make hard. No one upstream may be writing the fix you’d name, so someone has to patch the version you run and then confirm it still behaves the way your product expects. The alternative to patching is replacing the component, which usually means rework wherever your code uses it.

A workable order when you’re the one issuing the statements:

1. Make the SBOM match what ships. If it lists a component by mistake, correct the SBOM instead of issuing a not affected statement for that component.
2. Apply the fixes that exist, then issue fixed statements that name the versions containing them.
3. For components with no fix, decide among getting a patched version into your build, analyzing for a not affected statement, and issuing affected with an action statement.
4. Mark anything whose analysis is still underway as under investigation, and update the statement when the work is done. Any change raises the document version.

Each step leaves a record an auditor can check: the corrected SBOM, the fixed versions, the analysis in status notes, and the document’s version history.

Controlling What Enters the Build

Since a VEX status can’t show whether a package was tampered with or matches the source its project published, so build integrity needs its own control.

TuxCare’s SecureChain scans each package’s source code for malware and suspicious code patterns, blocks any package that fails, and rebuilds the rest from source in hardened, isolated environments. While upstream still ships fixes, it patches each package under a contractual SLA. All packages are delivered with SLSA (Supply-chain Levels for Software Artifacts) Level 3 provenance, SBOMs, and VEX statements. For the third route above, when upstream stops fixing a component, SecureChain automatically hands over to Endless Lifecycle Support (ELS), which continues delivering fixes after upstream maintenance ends. Coverage spans JavaScript, Python, Java, Go, and PHP ecosystems.

If you can’t say what went into a build, or your findings keep stalling on packages upstream has stopped fixing, ask our team how SecureChain handles it.

FAQ

Is VEX required by law?

The Vulnerability Exploitability eXchange (VEX) format isn’t a law. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) says its VEX minimum requirements aren’t official policy and don’t mandate compliance, and its 2026 software bill of materials (SBOM) minimum elements don’t list VEX as a required field. A customer contract can still require it.

Who can write a VEX statement?

A Vulnerability Exploitability eXchange (VEX) statement can come from the software’s supplier or from a third party, according to the U.S. Cybersecurity and Infrastructure Security Agency (CISA). The author must be named as an individual or an organization and is responsible for the content. The author can also record a role, such as vendor.

What is in a VEX file?

A Vulnerability Exploitability eXchange (VEX) file, which the U.S. Cybersecurity and Infrastructure Security Agency (CISA) calls a VEX document, holds document metadata and at least one statement. Each statement gives one status for one vulnerability across one or more products, plus any detail the status requires, such as an action statement or a justification.

What does it mean if a vulnerability has no VEX status?

Nothing can be concluded from it. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) says Vulnerability Exploitability eXchange (VEX) doesn’t imply any default status beyond what a statement explicitly provides, and a document may be incomplete. A vulnerability with no statement hasn’t been declared unaffected.

Does a VEX document need a signature?

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) says Vulnerability Exploitability eXchange (VEX) documents and statements should be signed, which makes signing a recommendation. The author’s identity should be tied to the signature, and a document’s signature has to cover all of its metadata and statements. Implementations must support commonly accepted signature mechanisms.

Can you use VEX without an SBOM?

Yes. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) says Vulnerability Exploitability eXchange (VEX) is designed to integrate with a software bill of materials (SBOM), vulnerability databases, and security advisories but doesn’t require any of them. When an SBOM exists, VEX product identifiers should reference its existing identifiers.

Summary

Article Name

How VEX Turns an SBOM Into Testable Audit Evidence

Description

Learn how VEX (Vulnerability Exploitability eXchange) states whether a vulnerability affects your product, and what it can and can’t prove.

Author

Artem Karasev

Publisher Name

TuxCare

Publisher Logo