> ## 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 Patches for Packages

> How Root Patches are applied to application packages - patch types, validation, and accessing patch metadata.

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:

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

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

```bash theme={null}
# 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](/concepts/provenance).

## Patch Freshness SLA

Root commits to having a patch available within:

| Severity | SLA                           |
| -------- | ----------------------------- |
| Critical | 7 days after CVE publication  |
| High     | 14 days after CVE publication |
| Medium   | 60 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](/concepts/vulnerability-statuses) for the complete status breakdown.