Do VEX Claims Age Well? Longitudinal Validation of 'Not Affected' and 'Fixed' Statements Against Subsequent Exploitation Evidence
Keywords:
VEX, OpenVEX, CycloneDX, vulnerability exploitability, statement aging, SBOM, exploitation evidence, digital trustAbstract
Background: Vulnerability Exploitability eXchange (VEX) documents carry status claims — "not affected," "affected," "fixed," "under investigation" — that determine whether a consumer acts on a vulnerability. The 2024–2025 ecosystem produced the first meaningful VEX corpus (OpenVEX adoption, CISA SBOM/VEX guidance, community tooling), and the companion conformance work in this issue established that the formats preserve semantics across OpenVEX, CycloneDX, and CSAF. What no one has examined is the temporal property: every VEX statement is a claim frozen at issuance time, and exploitation evidence that arrives later — KEV listings, EPSS movement, new PoCs — can silently invalidate a "not affected" claim that was true when written. Objective: We define the statement-aging problem for VEX, specify a validation protocol that measures claim validity against subsequent exploitation evidence, and assess the mechanisms available to revalidate statements over time. Methods: Analysis of VEX semantics under status-lifecycle stress; specification of a longitudinal revalidation protocol keyed to exploitation signals; and a risk-versus-mechanism coverage assessment. Results: Six aging risks emerge, of which three are structural: "not affected" claims cannot be falsified by the consumer without new evidence channels; "fixed" claims degrade silently with build drift; and downstream consumers cache statements with no expiry semantics — the VEX specification defines a status, not a validity horizon. The strongest mitigation is a versioned re-issuance policy with expiry metadata and KEV/EPSS cross-checks at refresh points; none of these is standardized in 2026. Conclusions: VEX statements should be treated as measurements with a validity horizon — revalidated on schedule, versioned on change, and expired explicitly. The specification work that made VEX interoperable now needs the temporal layer that makes it trustworthy over time.
References
1. Cybersecurity and Infrastructure Security Agency, "Vulnerability Exploitability eXchange (VEX) — Requirements and Considerations" and SBOM/VEX guidance documents, CISA, 2023-2024. [Online]. Available: https://www.cisa.gov/sbom
2. OpenVEX Working Group, "OpenVEX Specification v0.2.0," 2024. [Online]. Available: https://openvex.dev/docs/
3. "Augmenting Software Bills of Materials with Software Vulnerability Description: A Preliminary Study on GitHub," arXiv:2503.13998, 2025.
4. "On the adoption of software bill of materials in open-source software projects," Journal of Systems and Software, Dec. 2025. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0164121225002092
5. National Vulnerability Database, "Known Exploited Vulnerabilities (KEV) Catalog," CISA, updated continuously. [Online]. Available: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
6. FIRST, "Exploit Prediction Scoring System (EPSS)," updated daily. [Online]. Available: https://www.first.org/epss/
Downloads
Published
Issue
Section
License
Copyright (c) 2026 The author(s)

This work is licensed under a Creative Commons Attribution 4.0 International License.
AlphaTech Systems LLC publishes the version of record under the Creative Commons Attribution 4.0 International licence (CC BY 4.0), permitting sharing and adaptation for any purpose with appropriate attribution, a link to the licence, and an indication of changes. The public licence applies upon publication and is irrevocable for compliant users; submission alone does not license unpublished material.