Skip to main content
A Root Patch is the smallest safe fix for a vulnerable package. For application packages, Root Patches target the vulnerable code within a specific package version - without bumping to a newer release unless necessary.

​
What Gets Patched

Root Patches address vulnerabilities in application packages across supported ecosystems:
  • Python - packages on PyPI (e.g., requests, cryptography, django)
  • JavaScript - npm packages (e.g., axios, lodash, express)
  • Java - Maven artifacts (e.g., log4j-core, spring-core, jackson-databind)
Root patches the specific version you declared in your dependency file. Your requirements.txt, package.json, or pom.xml version string does not change - only the vulnerability is removed.

​
Two Patch Types

​
Backported Patches

Root takes the security fix from a newer upstream version and applies it to the exact version you declared. This is the preferred approach:
  • Your declared version stays the same (e.g., django==4.2.0 remains 4.2.0)
  • The fix is applied in-place to that version
  • Lockfiles remain stable - no pip-compile or npm install re-run needed (for Python and Java)
  • Downstream dependencies that require a specific version continue to resolve correctly
This is the same technique Linux distributions use to maintain long-term support branches - the same package version, with the security fix applied.

​
Native Distribution Package Upgrades

When the package maintainer has already released a patched version that is safe to upgrade to, Root applies the maintainer’s own update. Root evaluates this path when:
  • The upstream patch is a clean, minimal security-only fix
  • No breaking API changes were introduced in the patch version
  • The upgrade is safe for the version constraint you declared

​
How Patches Are Applied Without Version Bumps

Root patches packages in its registry at pkg.root.io. When you configure your package manager to use pkg.root.io, it resolves your declared version to Root’s patched variant transparently. For Python and Java, this is completely transparent - the version string is unchanged. For JavaScript, packages are published under the @rootio/ scope (since npm doesn’t allow republishing under the original name), and your package.json uses overrides / resolutions to redirect: 
{
  "dependencies": {
    "axios": "1.6.0"
  },
  "overrides": {
    "axios": "npm:@rootio/axios@1.6.0"
  }
}
Your application code still imports axios - resolution is handled transparently.

​
Viewing Patch History for a Package

Via the Root platform UI: Navigate to the Libraries section and find the package you’re interested in. The library report shows:
  • Which CVEs were fixed and when
  • The patch type applied for each fix
  • The full remediation timeline
Via the Root API: 
# Get patches for a specific package version
curl -H "Authorization: Bearer $ROOT_TOKEN" \
  "https://api.root.io/v1/packages/{pkgID}/artifacts/patches"

# Get provenance for a specific package version and architecture
curl -H "Authorization: Bearer $ROOT_TOKEN" \
  "https://pkg.root.io/packages/ecosystems/{ecosystem}/packages/{name}/versions/{version}/provenance/{arch}"
The patch feed is also publicly accessible: 
# Get all patches for a specific ecosystem
curl "https://api.root.io/external/patch_feed?ecosystem=pypi"
curl "https://api.root.io/external/patch_feed?ecosystem=npm"
curl "https://api.root.io/external/patch_feed?ecosystem=maven"

​
SBOM and VEX for Patched Packages

Every patched package includes updated security artifacts: SBOM: Updated to reflect the patched version of the vulnerable component. Download from the Root platform or API to confirm what’s in the patched package and use it in your supply chain tooling. VEX statement: Asserts non-exploitability for each patched CVE. Import into Grype, Trivy, or your ASPM to suppress patched findings from scanner output. Provenance attestation: A cryptographic record of Root’s AVR pipeline - which patch was applied, which tests passed, and when the fix was delivered. See Provenance.

​
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
When no upstream fix exists for a vulnerability, it enters No Fix Available status. Root monitors continuously and begins remediation automatically as soon as an upstream fix is available. See Vulnerability Statuses for the complete status breakdown.