VEX

VEX stands for “Vulnerability Exploitability eXchange”. A VEX document answers exactly one question for a given vulnerability and a given product: is this product affected?

The reason it exists is a practical problem. Matching a Software Bill of Materials (SBOM) against vulnerability databases regularly produces long hit lists. A large share of them lead nowhere, because the vulnerable function is not reachable in the product at all. Without a documented assessment, every one of those hits gets re-examined, on every scan, by every customer.

The four status values

• not affected means the vulnerability has no impact on this product. This status calls for a justification, such as the vulnerable code never being executed or being shielded by configuration.
• affected means the vulnerability does have an impact; a note on mitigations usually goes with it.
• fixed signals that a corrected version is available.
• under investigation says the assessment is still ongoing. That, too, is an honest and useful statement.

The first value is the interesting one. “Not affected”, with a reason someone can follow, is the statement that saves the most effort on both sides of the supply chain.

The justification is the actual content

A “not affected” without a justification is worthless. The recipient cannot tell whether the manufacturer assessed it carefully or simply does not want to deal with it. Five standardised justifications are therefore in common use:

• Component not present: the vulnerable subcomponent is not in the product at all, even though a naive match suggested it was.
• Vulnerable code not present: the component is included but the affected code is not, for instance because the build strips unused modules.
• Vulnerable code not in the execute path: the code is there but is never reached by the product.
• Vulnerable code cannot be controlled by an adversary: it does execute, but an attacker cannot influence the inputs required to exploit it.
• Inline mitigations already exist: exploitation is already prevented by protective mechanisms in the product.

The third is both the most common and the most demanding: it presupposes reachability analysis. Anyone stating it should record what it rests on. That is precisely the assertion likely to be examined later.

What belongs in a VEX document

Whatever the format, every statement needs four things to be machine-usable:

• a unique identifier for the product and its version, ideally the same one used in the Software Bill of Materials (SBOM)
• the vulnerability, usually via its CVE identifier
• the status and, for “not affected”, the justification
• a timestamp, because every statement only holds for one point in time

That last point is routinely underestimated. A VEX document is a snapshot: when the product version or the state of knowledge changes, the statement has to follow. An outdated “not affected” is worse than no statement at all.

Formats

VEX is a concept, not a single file format. Three implementations are common: as an extension of CycloneDX, as a profile of the CSAF advisory standard, and as a lightweight standalone format called OpenVEX. Which one fits depends on what the existing tooling and the customers work with.

Why the effort pays

VEX moves work from reaction into documentation. Instead of repeating the same analysis after every prominent vulnerability and answering the same customer questions one by one, the assessment is recorded once and passed on in machine-readable form.

The side effect matters directly for the Cyber Resilience Act (CRA): it creates an evidenced history of which vulnerability was assessed how, and when. That traceability is exactly what market surveillance authorities look for when they examine how vulnerabilities are handled.