VEX (Vulnerability Exploitability eXchange)

What Is VEX?

VEX — Vulnerability Exploitability eXchange — is a machine-readable statement that accompanies a software artifact and declares, for a specific vulnerability, whether that artifact is actually affected, and if not, why.

A scanner can tell you that a vulnerable component is present. It generally cannot tell you whether the vulnerable code path is reachable, whether a fix was backported without changing the version string, or whether a configuration already mitigates the issue. The result is a stream of findings that are technically accurate and practically irrelevant, with no standard way to say so.

VEX is the standard way to say so. Crucially it travels with the artifact, so the assertion reaches whoever scans it next — including a customer's security team, who would otherwise draw their own conclusion.

How a VEX Statement Is Structured

A VEX document binds three things together: a product identifier, a vulnerability identifier, and a status with a justification. CISA's minimum requirements define four status values:

• Not affected — the vulnerability does not impact this product. A justification is required, not optional.
• Affected — it does, and remediation or mitigation is recommended.
• Fixed — the vulnerability was present in this product and has been remediated in this version.
• Under investigation — the producer has not yet determined the status.

Using non-standard status values defeats the purpose entirely. The receiving tool cannot parse them, and an unparseable assertion is indistinguishable from no assertion at all.

Why VEX Matters More as Backporting Becomes Common

Most scanners identify vulnerabilities by matching installed package versions against a database. When a security fix is backported — applied to the version already in use rather than delivered by upgrading — package contents change while the version string does not.

The consequence is a genuinely patched artifact that reports a genuinely fixed CVE, in a tool behaving exactly as designed. VEX is the only standard mechanism for resolving that, and the reasons it beats the alternative are specific:

• It travels with the artifact, so downstream consumers see it without being told.
• It records a justification, not just a verdict, which is what an assessor asks for.
• It is machine-readable, so it resolves automatically rather than in a meeting.
• It survives a change of scanner, because it is not stored in any one tool's configuration.

How to Use VEX in Production Environments

VEX is only useful if it is produced consistently and consumed deliberately:

• Use the standard status values, since invented ones cannot be read by the tooling on the receiving end.
• Always supply a justification for "not affected", because a bare assertion is not evidence.
• Attach VEX to the artifact, not to a wiki page or a support ticket.
• Consume incoming VEX in your own pipeline, so suppliers' statements reduce your noise rather than being ignored.
• Prefer VEX over scanner suppression, which records the decision where only your team can see it.

How Hardened Container Images Deliver VEX

For an image provider, VEX is what makes a low CVE count verifiable rather than merely asserted. Without it, a consumer scanning the image independently has no way to distinguish a fixed vulnerability from an unaddressed one.

Echo states that VEX is delivered with each image alongside an SBOM and provenance data (echo.ai/product).

When evaluating any provider, the question worth asking is whether VEX accompanies every image automatically or is produced on request for disputed findings — the second is considerably less useful, because the disputes you never hear about are the ones that quietly cost you deals. The commercial side of this is covered in why most container security tools fail at vulnerability prioritization.

FAQs

How is VEX different from suppressing a finding?

Suppression records a decision inside your scanner, where downstream consumers cannot see it and a different tool will not honour it. VEX records the same decision inside the artifact, in a format the next reader's tooling can parse. The effort is comparable, and only one of the two survives a customer's independent scan.

Can VEX be used to hide real vulnerabilities?

A dishonest producer could issue a false "not affected" statement, which is why the standard requires a justification rather than a bare verdict. A justification is a checkable claim: a consumer can test whether the vulnerable code path is genuinely unreachable. VEX makes a misleading claim auditable rather than invisible.

Who produces VEX statements?

Usually whoever built the artifact, since they know what is inside it and how it was configured. Upstream maintainers sometimes publish VEX for their own components, and integrators may produce their own for a composed product. A VEX statement is scoped to a specific product identifier, so statements are not transferable between builds.

Does VEX require a particular SBOM format?

No. VEX can be expressed within CycloneDX, as a standalone CSAF document, or in the OpenVEX format, and the choice usually follows whatever your tooling already handles. What matters more is that the status values are the standard ones and the product identifier matches exactly what you shipped.

How fast should a VEX statement be issued?

Ideally with the artifact, covering known findings at build time, rather than in response to a customer escalation. Producing VEX reactively means every new consumer repeats the same discovery, and the statement arrives after the finding has already created doubt. Treat it as a build output, not an incident response artifact.