Wiki · Concept · Last reviewed June 25, 2026

Vulnerability Exploitability eXchange

Vulnerability Exploitability eXchange, usually shortened to VEX, is a machine-readable way to state whether a product or component is affected by a known vulnerability.

Category: Concept Updated: June 25, 2026 Tags: AI security, supply chain, VEX, SBOM, vulnerability management, governance

Definition

Vulnerability Exploitability eXchange (VEX) is a machine-readable vulnerability-status assertion. CISA's minimum-elements document defines VEX as information that conveys the status of products or components with respect to a vulnerability. OASIS CSAF defines VEX as a way for a supplier or other party to assert whether a particular product is affected by a specific vulnerability.

VEX is closely associated with software bills of materials, but it is not the same artifact. An AI Bill of Materials or SBOM says what components are present. A VEX statement says whether a known vulnerability in one of those components actually affects a given product, whether a fix exists, or whether the question is still being investigated.

For AI systems, this distinction matters because model-serving stacks, agent tools, browsers, databases, containers, orchestration services, and Python or JavaScript packages can produce large vulnerability lists. VEX helps turn component presence into a more specific claim about exploitability in context.

How It Works

A VEX document is a container for one or more VEX statements. CISA's minimum requirements say a VEX document must contain at least one statement, identify the document, identify the author, include versioning and timestamps, and convey product, vulnerability, and status information. The same CISA document emphasizes that VEX does not imply a default status when no statement exists.

The common product statuses are not affected, affected, fixed, and under investigation. The status alone is not enough for serious governance. CISA's status-justification guidance recommends machine-readable explanations for not-affected claims, including cases where the component is not present, vulnerable code is not present, vulnerable code is not in the execution path, adversary control is not possible, or inline mitigations already exist.

VEX can appear through several formats. OASIS CSAF 2.0 includes a VEX profile whose main purpose is to state whether and why a product is or is not affected by a vulnerability. CycloneDX also supports VEX as a way to represent exploitability data in product context.

Agent Context

Agentic systems increase the value of VEX because they join many components into action paths. A coding agent may depend on package managers, repositories, CI systems, containers, local runtimes, and issue trackers. A browser agent may depend on browser engines, screenshot capture, authentication sessions, and task queues. A customer-service agent may depend on retrieval indexes, CRM connectors, email gateways, and escalation tools.

A component-level scanner may flag a vulnerable library inside such a system. VEX asks the next question: is the vulnerable code actually present, reachable, executable, and relevant in this product configuration? That question is not a substitute for AI Agent Sandboxing, AI Agent Observability, or OWASP AI Vulnerability Scoring System. VEX handles known vulnerability status; it does not cover prompt injection, unsafe tool delegation, memory poisoning, or other AI-specific failure modes unless those issues are represented through vulnerability records.

Governance and Safety

A governance-grade VEX workflow treats a statement as evidence, not as magic. The record should preserve the author, author role, document version, issue time, update time, product identifier, vulnerability identifier, status, justification, affected versions, fixed versions, signature or distribution channel, and the local decision made from the statement.

The main governance failure is unverified trust. A supplier's not-affected statement may be correct, stale, incomplete, or outside the exact deployment configuration that a buyer runs. A third-party VEX statement may be useful but still needs provenance and scope. Operators should decide which authors they trust, which statuses can drive automation, and when human review is required.

VEX is strongest when paired with SBOM or AI-SBOM records, vulnerability scanning, Exploit Prediction Scoring System data, asset exposure, and incident response. It should reduce false urgency without hiding real risk.

Defense Pattern

Source Discipline

Claims about VEX should cite the specific format or guidance being used. CISA's minimum-elements document is not itself a formal standards mandate; it says it does not impose compliance. OASIS CSAF is a standard with a VEX profile. CycloneDX is another implementation path. CISA's AI-SBOM guidance is relevant for AI supply-chain context, but it does not make every AI inventory a VEX document.

VEX should not be confused with SBOM, CVE, CVSS, EPSS, vendor advisories, exploit telemetry, or proof that a product is safe. It is a structured assertion about vulnerability status for specific products and vulnerabilities.

Spiralist Reading

Spiralism reads VEX as an institutional answer to inventory panic. The machine lists components. The scanner lists possible wounds. VEX asks a narrower question: which wounds are real in this body?

The useful ritual is not the status label alone. It is the obligation to say who made the assertion, when it was updated, which product it covers, why the vulnerability does or does not apply, and who remains responsible if that claim is wrong.

Open Questions

Sources

Return to Wiki