Record a VEX decision for an exact product release
Connect a vulnerability applicability decision to a specific product, evidence, reviewer, and recheck trigger. Keep uncertainty visible in VEX records.
A vulnerability match identifies a component worth investigating. A VEX statement records the assessed impact on a particular product. Do not turn one investigation into a permanent dismissal for every release that contains the package. Start with the exact artifact, component occurrence, advisory identifier, and deployment assumptions.
Select the format before assigning a status
Status names are format-specific. CycloneDX 1.7 defines impact-analysis states including in_triage, exploitable, not_affected, and resolved. Investigation belongs in in_triage; resolved describes remediation. CycloneDX calls for a justification for not_affected cases. Do not copy a status label from another VEX format without checking its meaning and required fields.
The following is a review worksheet, not a serialized VEX document. Export the approved decision using the selected format's schema.
| Record field | Required local evidence |
|---|---|
| Product | Version, artifact digest, platform, and SBOM reference |
| Vulnerability | Advisory identifier and relevant aliases |
| Component | Exact occurrence and dependency path |
| Conclusion | Format-specific state and reason |
| Evidence | Build, code, configuration, or test references |
| Accountability | Author, reviewer, and decision timestamp |
| Recheck | Changed condition that invalidates the conclusion |
Test the reason, not only the label
For a claim that vulnerable code is absent, inspect the shipped artifact rather than only an import list. For a claim about an unreachable path, identify its entry points, configuration requirements, and alternate callers. A test that did not trigger the problem is not automatically proof that no path exists.
Record limits such as unsupported platforms, optional modules, or customer-controlled configuration. If those limits prevent a conclusion, retain the investigation state and assign the next evidence task. A patch planned for next week does not establish that the current release is remediated.
Publish a bounded, reviewable statement
Validate the exported document and confirm that the consuming system matches the intended product. Test a nearby version as a negative control: the decision must not suppress its alert accidentally. Keep the previous statement and the reason for any revision.
Set recheck triggers for changed builds, newly enabled features, revised affected ranges, and new evidence about reachability. Treat an external supplier's statement as an attributed assertion; check product identity and relevance before accepting it locally. The finished record should explain why the conclusion holds for this release and what would make the team investigate again.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.