Vulnerability scans produce identifiers faster than most teams can investigate them. A package is present in a container image, a CVE appears in a dependency report, and the next step is a decision about whether the product is affected. VEX, the Vulnerability Exploitability eXchange, was designed to communicate that decision in a machine-readable form. Its usefulness depends on whether the team records the reasoning and keeps it tied to a product version.
CSAF 2.1 defines a VEX profile inside a security advisory structure. The profile carries product relationships and vulnerability status statements. A status such as not affected, affected, fixed, or under investigation answers a different question than a scanner's package match. The exporter should supply a product identifier, the vulnerability identifier, a status, and a justification that an operator can review.
A scanner match is an input, not a disposition
A software bill of materials can show that a vulnerable library is installed. It cannot by itself show that the running product exposes the vulnerable code path, has the required configuration, or permits an attacker to reach it. That distinction is why an automated pipeline should create a triage item rather than mark every match resolved.
The decision record should name the exact product version and the affected component. If the vulnerable function is unreachable, record the evidence used to reach that conclusion. If the product wraps the library but removes the dangerous feature, record the version and configuration. If the evidence changes after a patch or a deployment, open a new decision rather than editing the historical package.
Do not let the scanner's severity field become the final risk rating. VEX statuses are about product applicability. Operational priority also depends on exposure, exploitability, compensating controls, data sensitivity, and the team's response window. A not affected statement can reduce patch urgency for a particular product, but it should not suppress monitoring for a later change that reintroduces the vulnerable component.
Attach a decision to the artifact
The most useful VEX statement travels with the release artifact or its advisory. It identifies the product at a granularity that the consumer can match, such as a package or component version. A publisher that supplies an arbitrary product name without a stable identifier makes automated consumption difficult.
Sign the advisory or transport it over an authenticated channel. The VEX statement communicates a security decision, so an attacker who can replace it can make a vulnerable dependency look harmless. Maintain provenance for the source data, the analysis environment, and the approval. If the advisory references a CSAF document, validate its signature and structure before applying its status to an inventory.
CSAF 2.1 also allows product trees and relationship statements. Use those fields when a product contains a component that is not itself shipped as the same product. The consumer should be able to determine whether a statement applies to the installed version, not guess from a free-form title. Ambiguity in the product identity weakens every downstream automation.
Make the decision expire with the evidence
A VEX decision is conditional on the evidence available at the time. New exploit code, a configuration change, a different build flag, or a newly discovered attack path can invalidate a not affected conclusion. Give each statement an owner, an evidence reference, and a review date. Reopen the decision when the dependency version, build process, or deployment model changes.
Keep the raw scanner result and the security decision separate. That separation preserves the ability to audit why a ticket disappeared from the queue. An operator should be able to see the original package match, the product identity, the accepted status, the justification, and the approver. A status with no provenance is difficult to defend during an incident or a customer review.
For an internal fleet, a useful workflow is: collect SBOM evidence, match the CVE to a product, assign a triage owner, record the applicability decision, validate the VEX against the release manifest, and schedule re-evaluation. The workflow should also generate a query for a scanner or an asset inventory. The final record answers a concrete question: for this product version, is this vulnerability applicable, why, and who will reconsider when the evidence changes?
Measure decisions rather than exemptions
Track the number of decisions awaiting evidence, the age of not affected claims, and the rate at which an earlier status is reversed. Those metrics reveal whether the organization is using VEX as an evidence workflow or as a way to silence alerts. A small number of well-supported decisions is better than a large set of statements copied from a vendor without checking the product version.
The defensive outcome is not a clean dashboard. It is an auditable trail that lets a responder answer which shipped products contain the vulnerable component, why a product was excluded, and what changed after an incident. VEX gives teams a format for that answer. The decision still has to be made with engineering evidence.