How do you use Trivy for VEX (Vulnerability Exploitability eXchange) and risk prioritization?

Think of VEX as a pharmacist's note attached to a drug interaction warning. When a pharmacy system flags a potential drug interaction, the pharmacist reviews the specific patient context and may annotate the warning as not clinically significant for this patient because the dosage is below the threshold, the patient is not in the at-risk population, or the interacting drug is being used topically rather than systemically. The warning remains in the system for audit purposes, but it no longer triggers alarms or blocks dispensing. VEX provides the same contextual override for vulnerability findings: the CVE exists in the dependency tree, but expert analysis has determined it is not exploitable in this specific application context, and that determination is recorded in a machine-readable, auditable format.

VEX stands for Vulnerability Exploitability eXchange, a standard format for communicating whether a product is affected by a specific vulnerability and why. The core insight behind VEX is that most CVEs detected by scanners like Trivy are not actually exploitable in every application that contains the vulnerable package. A CVE in a JSON parsing library's XML handling code is irrelevant to an application that never processes XML input. A buffer overflow in a networking function does not affect an application that uses a different code path through the library. Without VEX, security teams waste enormous time investigating vulnerabilities that pose no real risk, creating alert fatigue that causes them to miss genuinely dangerous findings. For enterprise services like payments-api, order-processing-service, and checkout-service, VEX documents reduce the actionable vulnerability count by 40-70 percent, allowing teams to focus their remediation efforts on findings that actually matter.

Trivy supports VEX consumption in two primary formats: OpenVEX and CSAF (Common Security Advisory Framework). An OpenVEX document is a JSON file that contains a list of statements, each specifying a product identifier, a vulnerability identifier (CVE), a status (not_affected, affected, fixed, or under_investigation), and a justification. When Trivy scans an image and finds CVE-2024-32002 in libcurl, and the team has published a VEX statement marking that CVE as not_affected for their product because the vulnerable SOCKS5 proxy code path is not reachable, Trivy automatically suppresses that finding from the scan results. The VEX document becomes part of the software supply chain metadata, stored alongside the SBOM and the image signature in the OCI registry as an attached artifact.

Risk prioritization extends beyond VEX to incorporate multiple contextual signals. Trivy's CVSS scoring provides a base severity, but enterprise risk prioritization layers additional factors: is the affected service internet-facing or internal-only, does it process sensitive data like payment card numbers or personal information, is the vulnerability actively exploited in the wild according to CISA's Known Exploited Vulnerabilities catalog, and what is the blast radius if the service is compromised. Teams build prioritization matrices that combine Trivy's vulnerability data with asset inventory metadata from their CMDB. A high-severity CVE in inventory-sync, an internal batch service running in an isolated network segment, receives a lower priority than a medium-severity CVE in checkout-service, which directly processes customer payment data over the internet. This risk-adjusted approach ensures that limited remediation engineering capacity is applied where it reduces the most actual risk.

The operational challenge with VEX at enterprise scale is maintaining the accuracy and currency of VEX statements across hundreds of services. When a VEX statement marks a CVE as not_affected because a specific code path is not used, that determination must be re-evaluated when the application code changes. A new feature that starts processing XML input invalidates the VEX statement that said the XML parsing vulnerability was not exploitable. Enterprise teams address this by integrating VEX statement management into the code review process: when application code changes in ways that could affect vulnerability exploitability, the VEX documents are reviewed and updated as part of the pull request. Automated tools can partially assist by analyzing code paths and flagging when a VEX justification may no longer hold, but human security engineering judgment remains essential for complex exploitability assessments. VEX documents also have an expiration model where statements must be reviewed periodically even without code changes, ensuring that evolving threat intelligence and new exploit techniques are considered.