VEX Statement Coverage
Root generates a VEX statement for every CVE it remediates. When AVR applies a Root Patch to an artifact:- The patch is validated and delivered
- A VEX statement is generated asserting non-exploitability for the patched CVE
- The VEX statement is attached to the artifact and made available via API and the Root platform
cr.root.io and pkg.root.io includes an up-to-date VEX statement covering all CVEs Root has addressed.
Accessing VEX Statements
Via the Root platform UI:- Navigate to your subscribed image or library
- Click the VEX button in the artifact panel
- The VEX document downloads to your browser
VEX Formats
Root generates VEX statements in two formats:| Format | Standard | Notes |
|---|---|---|
| CycloneDX VEX | CycloneDX 1.5 | Preferred - widest scanner support |
| OpenVEX | OpenVEX 0.2 | CISA-sponsored open standard |
not_affected- the CVE is not exploitable in this artifact (e.g., the vulnerable code path is not reachable)fixed- the CVE was present and Root applied a patch; the vulnerability is resolvedin_triage- Root is actively researching the vulnerabilityaffected- the vulnerability is present and awaiting a patch (rare - only when a patch is still being developed)
Using VEX with Scanners
Grype:fixed or not_affected in the VEX are suppressed from results.
Trivy:
VEX in Compliance Workflows
VEX statements provide audit-ready evidence that vulnerabilities have been addressed. For compliance packages:- Download the current VEX for each artifact in scope (via API or UI)
- Include the VEX alongside the SBOM in your compliance evidence package
- Reference the VEX in scanner configurations to show auditors that findings are suppressed for valid reasons
- The CVE identifier
- The artifact (image or package) the statement applies to
- The justification (
fixed) - The timestamp when the fix was applied
- The Root Patch reference (links to provenance)