Skip to main content
Root’s adoption model is designed to be easy to start and easy to maintain. There are no complex migrations and no breaking changes. The journey follows four stages.

The Adoption Journey

1

Discovery

Root identifies which images and libraries your organization is currently using. This gives you a complete picture of your open source footprint and its current vulnerability exposure before you change anything.
2

Subscription

You subscribe to Root’s secured equivalents for the images and packages in your inventory. Subscriptions are per-project — you choose what Root secures, and you stay in control.
3

Consumption

Point your Dockerfiles and package managers at Root’s registries. Pull and install exactly as you do today — the difference is that every artifact has already been through Root’s AVR pipeline.
4

Maintenance

Root monitors every subscribed artifact continuously. When a new CVE is published, AVR kicks in automatically — research, patch, test, deliver — and a patched version is available at Root’s registries before your next pull or install.

Root’s Two Registries

RegistryEndpointWhat it serves
Root Image Catalogcr.root.ioPatched container base images
Root Library Catalogpkg.root.ioPatched application packages
Both registries are fully compatible with their upstream equivalents. No tooling changes are required.

The AVR Pipeline

Every artifact in Root’s registries has passed through AVR — Root’s Agentic Vulnerability Remediation pipeline. When a new CVE is published, AVR automatically:
  1. Scans and detects — ingests the CVE within seconds, identifies affected components
  2. Builds a remediation plan — research agents analyze the vulnerability, locate upstream fixes, and assess compatibility
  3. Applies the fix — patching agents backport the fix to the exact version you’re running, preserving compatibility
  4. Tests and validates — the patch is verified against package tests, functional tests, and CVE-specific regression tests
  5. Delivers — the secured artifact is published to Root’s registries with updated SBOM, VEX, and provenance attestation
See AVR for the full technical breakdown.

No Code Changes Required

Root acts as a transparent registry. Package names, version numbers, tags, and APIs are identical to their upstream equivalents. You don’t update dependency files, lockfiles, or application code.

Transparency by Default

Every artifact Root delivers includes:
  • SBOM — a complete inventory of all components, including what was patched
  • VEX statement — which vulnerabilities were fixed and why the fix can be trusted
  • Provenance attestation — cryptographic proof of how and when Root built the artifact
These are available via the Root platform, the API, and as OCI annotations on images.