Skip to main content
A Root Patch is the smallest safe change that eliminates a known vulnerability in an open source package or container image. Root Patches are applied in-place — without bumping to a newer release or forcing a rebase — and every patch ships with updated SBOM, VEX, and provenance documentation.

​
The Core Principle

Root patches the version you’re already running. Your declared dependency version doesn’t change. Your lockfile stays stable. The vulnerability is removed from the version you chose, not replaced with a different version that may or may not be compatible with your application.

​
Two Patch Types

​
Backported Patches

A fix is taken from a newer upstream version and applied to the older version you’re running. This is the preferred approach when:
  • The upstream project has already fixed the issue in a newer release
  • Your application cannot safely upgrade to that newer release
  • The fix can be cleanly separated from other changes in the newer version
Root’s patching agents perform the backport, run the full test suite, and confirm the exploit is blocked before the patch ships.

​
Native Distribution Package Upgrades

When a Linux distribution (Debian, Ubuntu, Alpine, RHEL) has already released an updated package that includes the fix, Root applies the distribution’s own update. This approach is used when:
  • The distro’s security team has already done the backport work
  • The distribution’s package is available for the OS version in your image
  • The distribution’s update is the canonical fix for that platform

​
What Root Never Does

  • Force a major or minor version bump you didn’t ask for
  • Rebuild your image from a different upstream base
  • Change package APIs or behaviors
  • Introduce new dependencies beyond what the fix requires

​
Patch Validation

Every Root Patch is validated before delivery:
  1. Package test suite — the patched package’s own tests run against the fix
  2. Functional tests — end-to-end tests confirm the package behaves correctly after patching
  3. CVE regression tests — tests specific to the vulnerability confirm the exploit path is blocked
  4. Compatibility checks — downstream dependencies are tested against the patched version
A patch that fails any of these stages is not shipped.

​
Patch Transparency

Each Root Patch is documented in the artifact’s SBOM and VEX statement:
  • SBOM — the component inventory is updated to reflect the patched version of the vulnerable package
  • VEX — a statement is generated asserting the CVE is fixed in this artifact, with the remediation approach documented
  • Provenance — the full build record, including test results, is included as a cryptographic attestation
See SBOMs, VEX Statements, and Provenance for details.