What a VEX document actually communicates
Vulnerability Exploitability eXchange (VEX) is a machine-readable way to communicate whether a known vulnerability affects a specific product or component in context. It complements an SBOM: the SBOM establishes component presence, while VEX records a scoped exploitability status and its justification.
A VEX document does not prove that a product is secure. It carries a decision claim that should remain traceable to product and version scope, technical rationale and reviewable evidence. The Software Integrity reading path places that claim inside the wider build, release and lifecycle evidence chain.
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.
A VEX status becomes operationally useful only when the product/version claim, exploitability rationale and supporting evidence remain traceable to the release decision.
Can the organisation reproduce the technical justification behind every high-consequence “not affected” statement?
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.
- Require product/version scope on every VEX statement.
- Record technical justification and evidence owner.
- Reassess when configurations or threat knowledge change.
- Separate “not affected” from “fixed” and “under investigation”.
- Use supplier VEX as input to, not replacement for, final product risk decisions.
Continue this decision.
Signed AAOS firmware can remain authentic while carrying exploitable dependencies, turning vulnerability remediation into a lifecycle and supply-chain governance problem.