Skip to main content
Root generates VEX statements for every patched vulnerability, enabling your scanners to distinguish between unaddressed CVEs and those already fixed by Root. This eliminates noise in scanner output and keeps compliance reports accurate.

​
VEX Statement Coverage

Root generates a VEX statement for every CVE it remediates. When AVR applies a Root Patch to an artifact:
  1. The patch is validated and delivered
  2. A VEX statement is generated asserting non-exploitability for the patched CVE
  3. The VEX statement is attached to the artifact and made available via API and the Root platform
VEX statements are generated within minutes of patch delivery. Every artifact from 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:
  1. Navigate to your subscribed image or library
  2. Click the VEX button in the artifact panel
  3. The VEX document downloads to your browser
Via the Root API: For container images:
For AVR artifacts (image vulnerability remediations):
OCI annotations (container images): VEX statements are attached as OCI annotations and can be retrieved using standard tooling:

​
VEX Formats

Root generates VEX statements in two formats: Both formats carry the same information. Choose based on your tooling’s support. Root’s justification vocabulary: Root uses the following VEX status values for patched vulnerabilities:
  • 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 resolved
  • in_triage - Root is actively researching the vulnerability
  • affected - the vulnerability is present and awaiting a patch (rare - only when a patch is still being developed)

​
Using VEX with Scanners

Grype:
Grype 0.72.0+ supports VEX natively. Findings marked fixed or not_affected in the VEX are suppressed from results. Trivy:
Snyk: Use Snyk’s suppression API to mark patched findings as resolved, referencing the Root VEX statement as evidence:
Wiz / Orca: Import Root VEX statements via the platform’s SBOM/VEX upload interface. Both platforms support CycloneDX VEX for suppressing findings.

​
VEX in Compliance Workflows

VEX statements provide audit-ready evidence that vulnerabilities have been addressed. For compliance packages:
  1. Download the current VEX for each artifact in scope (via API or UI)
  2. Include the VEX alongside the SBOM in your compliance evidence package
  3. Reference the VEX in scanner configurations to show auditors that findings are suppressed for valid reasons
For each fixed CVE, the VEX statement includes:
  • 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)
This gives auditors traceable, verifiable evidence that the vulnerability was remediated - not just suppressed without justification.