> ## 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.

# VEX Reports

> Accessing and using Root's VEX statements to suppress patched findings in vulnerability scanners.

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:

```bash theme={null}
# 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):

```bash theme={null}
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:

```bash theme={null}
# 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:

| Format            | Standard      | Notes                              |
| ----------------- | ------------- | ---------------------------------- |
| **CycloneDX VEX** | CycloneDX 1.5 | Preferred - widest scanner support |
| **OpenVEX**       | OpenVEX 0.2   | CISA-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:**

```bash theme={null}
# 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:**

```bash theme={null}
# 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:

```bash theme={null}
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.