Understand the VEX analysis states: not_affected, affected, fixed, and under_investigation; choose not_affected when the CVE is present in a dependency but your product does not exercise the vulnerable code path.
Author a CycloneDX VEX JSON document with a vulnerabilities array; for each entry set the id to the CVE identifier, the analysis.state to not_affected, and populate analysis.justification with one of the defined CycloneDX justification codes (e.g., code_not_reachable).
Reference the SBOM BOM serial number and version in the VEX document's metadata to associate the VEX with a specific SBOM generation.
Publish the VEX document alongside the SBOM (e.g., as a cosign attestation or as a file in a release artifact bundle) so downstream consumers can apply it when scanning.
Pass the VEX document to vulnerability scanners that support VEX filtering (e.g., Trivy with --vex) to suppress not_affected findings from scan reports.
Known gotchas
VEX documents are assertions, not guarantees; your justification and analysis must be accurate — incorrect not_affected statements can mask real vulnerabilities from downstream operators.
CycloneDX VEX and CSAF VEX are separate formats with different schemas; confirm which format your downstream tools (scanners, SCA platforms) accept before authoring.
VEX documents have no inherent expiry; establish a review process to revisit not_affected statements when the CVE or the affected component's usage changes.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp