Skip to main content
A Root Patch is the smallest safe fix for a vulnerable package. For container images, Root Patches target OS-level packages (installed via apt, apk, yum) and language runtime packages installed inside the image.

​
What Gets Patched

Root Patches address vulnerabilities in:
  • OS packages - packages installed by the distribution package manager (apt, apk, yum)
  • Language runtimes - the runtime interpreter itself (Python, Node.js, Ruby, etc.) when the vulnerability is in the runtime
  • Installed application dependencies - packages added via pip install, npm install, gem install, etc. in the Dockerfile
Root patches each of these in place. It does not rebuild the image from a different upstream base, change the OS version, or introduce incompatible package API changes.

​
Two Patch Types

​
Backported Patches

Root takes a security fix from a newer upstream version and applies it to the older version present in the image. This is the preferred approach when:
  • The upstream project has already fixed the issue in a newer release
  • The fix can be cleanly separated from other changes in the newer version
  • Your image needs to stay on the older version for compatibility
The patched package keeps its original version number in the SBOM - the fix is applied in-place.

​
Native Distribution Package Upgrades

When a Linux distribution’s security team has already released a patched package (e.g., via Debian Security, Ubuntu Security, Alpine packages), Root applies the distribution’s own update. This is used when:
  • The distro’s security team has already performed the backport
  • The patched package is available for the specific OS version in the image
  • The distribution’s update is the canonical fix for that platform

​
How Patches Are Applied Without Rebuilding

Root’s AVR pipeline modifies only the vulnerable packages within the existing image layers. It does not:
  • Rebase to a different upstream version
  • Change the OS or distribution
  • Alter unrelated packages or configurations
  • Introduce new dependencies beyond what the fix requires
This means your image continues to work exactly as before - same entrypoints, same environment variables, same behavior - with the vulnerable code replaced.

​
Viewing Patch History for an Image

Via the Root platform UI:
  1. Navigate to your subscribed image in the Root platform
  2. Select the image tag you’re interested in
  3. Open Patch Explorer - a human-readable view showing:
    • Which CVEs were fixed and when
    • The patch type applied (backport or distribution upgrade)
    • Before/after package version comparison
    • Test results for each patch
Via the Root API: 
# Get SBOM for a specific tag (includes all patched packages)
curl -H "Authorization: Bearer $ROOT_TOKEN" \
  "https://api.root.io/v1/images/tags/{rrtID}/sbom"

# Get VEX statements (CVEs fixed in this tag)
curl -H "Authorization: Bearer $ROOT_TOKEN" \
  "https://api.root.io/v1/images/tags/{rrtID}/vex"

# Get provenance attestation (build record)
curl -H "Authorization: Bearer $ROOT_TOKEN" \
  "https://api.root.io/v1/images/tags/{rrtID}/provenance"

​
SBOM and VEX for Patched Images

Every time Root applies a patch to an image, it generates updated security artifacts: SBOM (CycloneDX or SPDX): The component inventory is updated to reflect the patched version of each vulnerable package. You can use the updated SBOM to confirm exactly what’s in the image and verify that vulnerable packages have been addressed. VEX statement: A VEX (Vulnerability Exploitability eXchange) statement is generated for each patched CVE, documenting the fix and asserting non-exploitability. Import VEX into Grype, Trivy, or your ASPM to suppress findings for patched CVEs. Provenance attestation: A cryptographic record of the AVR pipeline build - what was patched, how, when, and what tests passed. See Provenance for details.

​
Patch Freshness SLA

Root commits to having a patch available within:
SeveritySLA
Critical7 days after CVE publication
High14 days after CVE publication
Medium60 days after CVE publication
In practice, Root often delivers patches significantly faster than the SLA - especially for Critical and High severity CVEs where automated remediation proceeds as soon as an upstream fix is available. If no upstream fix exists, the CVE enters No Fix Available status. Root monitors continuously and begins remediation automatically as soon as a fix becomes available. See Vulnerability Statuses for the complete status breakdown.