VEX Guide: Vulnerability Exploitability eXchange Explained

What VEX Actually Is

VEX is a structured, machine-readable assertion that pairs one product (or product version) with one vulnerability and asserts whether the vulnerability is exploitable in that product. The assertion is small on purpose. VEX does not duplicate the CVE record, it does not score the vulnerability, and it does not describe the underlying flaw. VEX answers exactly one operational question: given that the world says CVE-X is in component Y, and component Y is inside product Z, can someone actually exploit CVE-X by interacting with product Z as it ships.

The reason VEX exists as a distinct artefact rather than a free-text security advisory is that downstream vulnerability management programmes are now automated. SBOMs are ingested by tooling, components are matched against vulnerability data, and findings are opened on whichever product carries the affected component. A free-text PDF advisory cannot stop that machine. A VEX document written to CSAF or CycloneDX can be parsed by the same ingestion pipeline that generated the false positive in the first place and can suppress, defer, or close the finding with an auditable justification.

VEX is not a substitute for a security advisory. A vendor publishing a VEX document is asserting an exploitability decision, not describing how to mitigate, what to patch, or when a fix will ship. Where VEX overlaps with an advisory, the two are usually published together: the VEX is the structured machine claim, the advisory is the human narrative that explains why.

The Four CISA VEX Status Values

CISA defines four VEX status values for any (product, vulnerability) pair. Every VEX statement carries exactly one. The status drives the behaviour of the consumer's ingestion pipeline.

The four-status set is deliberately small. A consumer ingesting hundreds or thousands of VEX statements per release does not need a long taxonomy; they need a small, stable set of values their pipeline can route automatically. The five-justification set that hangs off not-affected is where the nuance lives.

The Five Not-Affected Justifications

A not-affected status without a justification is not an audit-ready VEX. CISA defines five justifications, and every not-affected statement should pick one. Without the justification, a downstream consumer cannot tell the difference between a defensible assertion and a vendor that simply does not want to fix the issue.

A VEX statement that carries a justification a consumer can audit is the operational difference between a credible vendor and a vendor that ships unverifiable claims. When the justification is wrong, the consumer can challenge it. When there is no justification, the consumer ignores the statement and opens the finding anyway.

CSAF VEX and CycloneDX VEX: Two Formats, One Idea

VEX exists in two dominant machine-readable formats. CSAF VEX is a profile of the OASIS Common Security Advisory Framework (CSAF) standard, expressed as a vendor-style advisory document with a vex profile applied. CycloneDX VEX is a vulnerability section inside a CycloneDX document, either embedded in the SBOM itself or shipped as a sibling document. Both formats carry the same four status values and the same five not-affected justifications. Choosing between them is a question of which fits your existing advisory and SBOM pipeline.

A reasonable default for an AppSec-led programme that already produces CycloneDX SBOMs is CycloneDX VEX in the same document or as a sibling. A reasonable default for a product security organisation that already publishes CSAF advisories to a customer advisory portal is CSAF VEX. Many vendors produce both: the CSAF VEX is the customer-facing advisory artefact, and the CycloneDX VEX is the build-pipeline artefact that ships next to the SBOM. Both formats are interchangeable in meaning; the transformation between them preserves status and justification.

VEX and SBOM: The Producer-to-Consumer Story

VEX only earns its place in the vulnerability management stack when it sits next to an SBOM. The SBOM tells the consumer which components the product contains. The VEX tells the consumer which advertised vulnerabilities in those components actually apply. Read together, the two artefacts collapse most of the false-positive noise that SBOM-only ingestion produces.

The producer side is the supplier. The supplier ships the SBOM that lists components, ships the VEX statements that assert which vulnerabilities apply, and ships the advisories that explain why. The consumer side ingests the SBOM, matches components against vulnerability data, applies VEX statements to suppress or defer false positives, then runs the residual set through the standard vulnerability management lifecycle.

Producing VEX: The Vendor Workflow

For a vendor shipping software to other organisations, VEX production is mostly a workflow problem rather than a tooling problem. The status decision exists somewhere inside the engineering organisation already; VEX is the discipline that captures the decision in a structured artefact the customer can ingest.

The producer-side workflow is most of the operating cost of VEX. The format is solved. What is hard is sustaining the triage discipline so the customer is reading current VEX statements rather than stale ones.

Consuming VEX: The Buyer Workflow

For a buyer ingesting VEX from upstream vendors, the workflow inverts the producer side. The buyer is reading vendor assertions and deciding whether to trust them, route them, suppress findings against them, or challenge them when the assertion looks weak.

The consumer side is where VEX pays for itself. A programme that ingests VEX consistently can collapse the SBOM-derived false-positive load by an order of magnitude and free vulnerability management capacity for the affected statements that actually matter.

VEX as Audit Evidence

VEX is increasingly treated as a primary or supporting audit artefact, especially in regulated sectors and federal procurement. The exact treatment varies by regime, but the operating posture is consistent: produce VEX statements for the vulnerabilities you ship against, ingest VEX statements for the software you operate, retain history, and be able to show the lifecycle of each statement.

The audit-evidence pack sits on the artefacts and on the lifecycle. The VEX statement itself is the evidence the disposition exists; the supersession chain (under investigation, not affected with justification, fixed when a release ships) is the evidence the disposition has been maintained as the product evolved.

Common VEX Failure Modes

The artefact is straightforward. The operating discipline is where programmes break. These are the failure modes that show up most often in real audit conversations.

1. Not-affected without justification. A bare not-affected status is not auditable. Every not-affected statement must carry one of the five justifications, and the justification must be specific enough that a consumer can challenge it.
2. Under-investigation forever. A holding status is acceptable for days or weeks. After that, the consumer cannot tell the difference between active triage and a vendor that has stopped responding. Every under-investigation statement should set an explicit follow-up date.
3. No supersession chain. A VEX statement that changes from not-affected to affected because new evidence emerged should produce a new statement that names the previous one. Without the chain, the consumer cannot reconstruct the disposition history.
4. VEX without an SBOM. A VEX statement against a product the consumer cannot tie to a specific build is unactionable. The SBOM identifies the components; the VEX asserts exploitability against those components. Both have to be on the record.
5. Format mismatch with the consumer pipeline. Some vendors publish CSAF VEX while the consumer ingestion expects CycloneDX VEX, or vice versa. Either side can convert, but the conversion path must be documented and the converted document should preserve the original signature reference.
6. Stale statements after a fix release. A VEX statement that says affected for a product version that is now end-of-life produces noise without value. The supersession discipline should retire affected statements when the product is retired and the consumer should garbage-collect VEX against versions they no longer run.
7. VEX treated as marketing. A vendor that publishes blanket not-affected statements without doing the triage work loses credibility on the first audit. Consumers compare not-affected justifications across advisories and notice when the same boilerplate text repeats across unrelated CVEs.

A Four-Week VEX Programme Rollout

For an internal team standing up a VEX programme from a clean start, a four-week rollout is enough to wire VEX into the existing SBOM and SCA pipeline against a small, well-bounded product set.

Four weeks is enough for a clean rollout against a well-bounded product or supplier set. Programmes that try to standardise VEX across an entire vendor portfolio in the same window usually slip; pick a beachhead, prove the workflow there, then extend.

Where VEX Sits in the Wider Security Org

VEX is a cross-functional artefact. AppSec owns the build-time triage that decides whether vulnerable code is reachable. Vulnerability management owns the consumer-side ingestion and routing. Product security owns the customer-facing publication of VEX statements. GRC owns the procurement-side expectation that suppliers ship VEX. CISOs read the programme-level posture, including the reach of VEX across the supplier portfolio.

Each function reads the same VEX statement through a different lens. The not-affected statement that AppSec authored after a code-path review is the same statement that vulnerability management uses to suppress a finding, that product security ships in the customer advisory portal, that GRC cites in the audit evidence pack, and that the CISO reads as a top-disposition metric. As long as all five functions read the same record, the VEX programme stays coherent.

• AppSec teams own the build-time triage, the reachability analysis, and the not-affected justifications that hold up under audit.
• Vulnerability management teams own the consumer-side ingestion and the routing of affected, fixed, not-affected, and under-investigation statements through the standard lifecycle.
• Product security teams own the customer-facing publication of VEX statements alongside CSAF advisories and the supersession discipline across product releases.
• GRC and compliance teams own the procurement clauses that ask suppliers for VEX, the framework mapping under EO 14028, NIS2, DORA, FDA, PCI DSS, ISO 27001, and SOC 2, and the audit-evidence pack that proves the lifecycle is operating.
• Security engineering teams own the platform that ingests, parses, signs, stores, and serves VEX across the programme.
• CISOs read the programme-level VEX coverage, the supersession discipline, and the top-disposition mix as part of the leadership posture rather than as a separate report.

VEX and the Existing SecPortal Stack

SecPortal does not parse VEX files natively. The product runs SCA against connected repositories using package-manager-native tooling and correlates results against the National Vulnerability Database, which produces the per-component CVE picture a VEX statement would otherwise filter. For programmes that operate a separate VEX pipeline, the SecPortal engagement record carries the VEX document as a stored artefact, the disposition decision as comments and finding state changes, and the audit evidence on the same activity log that covers scanner-led work.

• Code scanning runs Semgrep SAST plus npm audit, pip-audit, and govulncheck SCA against connected repositories and produces the per-component CVE picture that VEX statements suppress, defer, or escalate.
• Repository connections wire GitHub, GitLab, and Bitbucket through OAuth so the same code under triage is the code SecPortal runs SCA against.
• Findings management carries each SCA-derived finding with CVSS 3.1, persistent identifier, owner, evidence, and remediation status across the lifecycle, so a VEX disposition decision is captured against the same finding identifier across releases.
• Document management stores the VEX document alongside the parent SBOM as engagement-attached artefacts under signed-URL retrieval and the standard 50 MB per-file allowlist.
• Continuous monitoring keeps SCA running on a daily, weekly, biweekly, or monthly cadence so the VEX-aligned picture stays fresh between releases of the upstream software.
• Activity log captures the timestamped chain of finding state changes, document uploads, and team actions that auditors look for as evidence the VEX disposition decisions are being acted on.
• Compliance tracking maps VEX-driven dispositions against ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST controls and exports the evidence to CSV.
• AI reports produce the executive summary, technical report, and remediation roadmap views from the same engagement record so leadership reads the VEX-filtered residual risk alongside everything else.

None of these features parse VEX files. The VEX is yours to author or to ingest. What the platform does is keep the resulting findings, the VEX document, the lifecycle, the framework mapping, and the leadership read on the same record so the audit conversation collapses into a query rather than a multi-team evidence scramble.

Wider Reading

VEX intersects with several other parts of the vulnerability management and AppSec programme. The following pages cover the adjacent disciplines from different angles and feed back into the VEX workflow.

• SBOM guide for the parent inventory artefact that VEX layers exploitability assertions on top of.
• CISA KEV catalog operational guide for the observed-exploitation signal that VEX-affected statements often coincide with.
• EPSS score explained for the predicted-likelihood signal that prioritises the VEX-affected residual queue.
• CVSS scoring explained for the technical-severity signal that scores the affected and fixed statements.
• Vulnerability prioritisation framework for the signal-weighting policy that VEX-filtered findings flow through.
• Vulnerability acceptance and exception management for the deferred-risk side that low-trust not-affected statements feed into when the consumer cannot fully suppress.
• Vulnerability prioritisation use case for the operational workflow that ranks VEX-affected residuals against scanner-led findings on the same record.
• Security exception register template for the org-wide ledger that records the upstream not-affected justifications you accepted at audit-defensible quality.
• Audit evidence half-life research for the evidence-side analysis of why a stored VEX statement stops counting after a defined window.
• ISO 27001, SOC 2, PCI DSS, and NIST for the framework-side mapping that VEX-derived evidence flows into.

Run VEX-Aware Vulnerability Management on a Single Record

VEX is mostly a recordkeeping problem in disguise. The status set is small, the justifications are well defined, and the format choice is not the bottleneck. What stops most programmes is that the VEX document lives in one place, the SCA findings live in another, the disposition history lives in a ticketing system, the supersession chain lives in email, and the framework mapping is in a spreadsheet. Producing the audit evidence pack means reconciling four or five sources at audit time, and producing the leadership read means reconciling them again.

SecPortal is built around a single engagement record where SCA findings, attached VEX documents, disposition comments, finding lifecycle, framework mapping, leadership read, and activity audit trail all sit on the same workspace. The platform does not parse the VEX file for you. What it does is keep the rest of the programme on one record so the VEX you author or ingest somewhere else turns into VM evidence on the engagement record without the multi-tool reconciliation that usually breaks the audit conversation.