How VEX Justification Types Should Determine the Scope of Vulnerability Decisions

Vulnerability scanners repeatedly flag the same CVEs across builds, and VEX documents are designed to record triage decisions once — but applying those decisions too broadly or too narrowly creates serious accuracy problems. Pinning every decision to an exact product-and-dependency version tuple is honest but impractical, causing teams to rubber-stamp re-triage queues without genuine review. Conversely, declaring a CVE non-applicable across all versions is convenient but can silently remain in force after the underlying facts change. Under the OpenVEX specification, four of the five available justification types are assertions about a product's own code, configuration, or call graph, making them legitimately broad in scope, while one type — vulnerable_code_not_present — is specifically tied to a dependency version and should never be carried across a version bump. The author argues that a decision's valid scope is determined by its justification type, meaning a mismatch between the two is a detectable bug that should eventually be enforced by tooling rather than manual review.