VEX statements: cutting false positives without hiding real risk

A bill of materials tells you which components a product contains. It does not tell you whether a reported flaw in one of those components affects the product as shipped. Vendors that answer that question in a machine-readable form publish a VEX statement.

What the document asserts

VEX, short for Vulnerability Exploitability eXchange, records a vendor's position on a specific vulnerability in a specific product, for a defined version range. The common statuses are not affected, affected, fixed, and under investigation.

Each status needs a justification. A component can be present but unreachable, present but compiled without the vulnerable feature, or mitigated by configuration. The justification field is where that reasoning lives.

Why teams ask for one

Scanning an artifact against a vulnerability feed produces a long list. Much of it is real. Some of it is noise from a library that is bundled but never invokes the affected code path. Without a vendor statement, every consumer redoes the same analysis.

A VEX feed lets an organisation suppress a confirmed not-affected finding and keep the inventory honest, because the record of why it was suppressed travels with the data.

Reading one critically

A not-affected claim is only as good as its justification. The four common ones are: the vulnerable code is not present, the vulnerable code cannot be controlled by an attacker, the vulnerable code is not reachable in the default configuration, or the product does not include the component at all.

Buyers should check that the statement covers the deployed version, that it names a product identifier they recognise, and that it was issued after the vulnerability was published. A statement that predates the disclosure that prompted it means nothing.

Where VEX does not help

VEX covers a vendor's own product. It says nothing about the customer's configuration, the customer's own code, or third-party plugins the customer added. It is a starting point for triage rather than a substitute for it.

It also does not address whether an attacker can chain the component with another weakness in the same product. That question needs its own assessment.

References

• CISA, VEX overview: https://www.cisa.gov/sbom
• OpenVEX specification: https://github.com/openvex/spec
• CycloneDX VEX: https://cyclonedx.org/capabilities/vex/