A VEX Statement Is a Claim That Needs Evidence

SBOM presence and product exploitability are different questions

An SBOM can show that a vulnerable component exists in a product. It cannot by itself prove that the vulnerable code is reachable, configured, executed or exposed in the deployed product context. VEX was created to communicate that contextual exploitability status.

CISA’s SBOM resource library includes VEX guidance, minimum requirements, status justifications and use cases. CycloneDX similarly represents VEX as a way to describe exploitability in the context of the product that contains the component.

That distinction is essential in embedded and automotive systems where the same library can appear across multiple ECUs, build variants and feature configurations with very different attack paths.

The hard part is the justification behind the status

A “not affected” statement should therefore be treated as a technical claim with an owner, scope, version and rationale. Examples include a vulnerable function not being compiled, the code path being unreachable, a required configuration being absent or an effective mitigation blocking exploitation.

NIST SSDF provides the complementary lifecycle discipline around component provenance and vulnerability response. The strongest VEX process connects the statement to evidence that can be reviewed again when the product configuration or vulnerability understanding changes.

If a supplier cannot explain the technical basis for a VEX status quickly, the statement may reduce scanner noise while increasing decision risk. The useful output is not fewer CVEs on a dashboard. It is faster, defensible prioritisation.