Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.root.io/llms.txt

Use this file to discover all available pages before exploring further.

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: 
# Get VEX download URL for an image tag
curl -H "Authorization: Bearer $ROOT_TOKEN" \
  "https://api.root.io/v1/images/tags/{rrtID}/vex"

# The response is a presigned URL - fetch the VEX from it:
curl -o vex.json "https://..."
For AVR artifacts (image vulnerability remediations): 
curl -H "Authorization: Bearer $ROOT_TOKEN" \
  "https://api.root.io/v1/avrs/{avrID}/artifacts/vex"
OCI annotations (container images): VEX statements are attached as OCI annotations and can be retrieved using standard tooling: 
# Using cosign
cosign verify-attestation --type vex cr.root.io/python:3.12-slim

# Using oras
oras pull cr.root.io/python:3.12-slim --media-type application/vnd.cyclonedx+json

​
VEX Formats

Root generates VEX statements in two formats:
FormatStandardNotes
CycloneDX VEXCycloneDX 1.5Preferred - widest scanner support
OpenVEXOpenVEX 0.2CISA-sponsored open standard
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: 
# Pass VEX document to suppress patched findings
grype cr.root.io/python:3.12-slim --vex vex.json

# Or use the SBOM + VEX together
grype sbom:sbom.json --vex vex.json
Grype 0.72.0+ supports VEX natively. Findings marked fixed or not_affected in the VEX are suppressed from results. Trivy: 
# Trivy VEX support (v0.46.0+)
trivy image --vex vex.json cr.root.io/python:3.12-slim

# Or with a local SBOM
trivy sbom --vex vex.json sbom.json
Snyk: Use Snyk’s suppression API to mark patched findings as resolved, referencing the Root VEX statement as evidence: 
snyk ignore --id=SNYK-VULN-ID \
  --reason="Patched by Root - see VEX statement" \
  --expiry=2099-12-31
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.