Overview - Root Patch Curation

As explained earlier, vulnerable packages for which no fix was found during the AVR Remediation Flow, are added to the work queue for offline Root Patch curation. This is a continuous, offline process where Root constantly monitors for new vulnerabilities and adds new Root Patches to the repo. Root's agentic fleet and human experts work in tandem—agents perform automated research, patch sourcing, and backport analysis, while human reviewers validate and approve fixes before they are put into production.

The output of this process is a fix package of one of the types described below

Native Distribution Upgrade Package:

These are packages in which the vulnerability has been fixed by the original package maintainer.

Root Patch:

When no Native Distribution Package is available for the specific distribution version, Root creates a Root Patch. These include surgical fixes backported from existing validated sources or created in-house when no upstream fix exists. Agentic systems identify and analyze fix sources, while, at each step in the process, human experts review, test, and approve all patches before they enter the library.

This page provides a detailed explanation of Root Patches and the overall fix curation process.

How Are Root Patches Created?

Design Principles

Two main principles guide us when we create Root Patches.

• Reduce vulnerabilities in your container image to near zero.
• Maintain full alignment with the open-source ecosystem by avoiding proprietary or closed-source packages.

1️⃣ Search for Fix-Candidate

We begin by searching for a fix-candidate. This is a package that, while not explicitly coded for your OS version, fixes the vulnerability. The search process is performed by agentic systems that scan upstream sources, community repositories, and internal patch inventories. Root AI research agents gather all upstream patches available that address the CVE, across a wide range of sources.

This includes scraping previous versions of the target Linux distribution (such as older Ubuntu releases) and patches developed for similar Linux distributions like Alpine or Debian that address the same CVE. Candidate patches are prioritized if they are community-approved and widely used, as these have already been proven safe in production environments. Our agentic-AI researchers study and analyze the packages they gathered and create a fix plan that indicates a fix candidate and an implementation approach.

Root applies version-safety criteria when selecting a fix candidate, and at each step in this process, Root human security and coding experts assess the recommendations of the AI agents. In choosing a fix candidate we pick upstream upgrades that have the smallest possible semantic version difference from the target package.

After review and approval by the human experts, a final implementation plan is created for the Root Patch.

2️⃣ Code the Root Patch

Now our AI development agents go to work to create a Root Patch based on the Implementation plan. This is a complex and detailed design process and is always reviewed and approved by a team of human security and coding experts.

While the methods used for coding Root Patches vary greatly, a basic example might look like this:

• The fix-candidate is an existing, generic package in which the CVE has been corrected for a different OS version than the target package. In the fix-candidate we identify the delta from its earlier, vulnerable version. For example, this might be one or two rows of code that have been changed.
• We apply the changes to the target version/fix candidate.
• Compile and test the new package.

If you would like to see the impact of the changes in the Root Patch, you can view the delta in the code from the admin portal.

The example below shows the delta in the code for the library libaom3 as displayed on the Inventory page,

3️⃣ Put Root Patch into Production

Once a Root Patch is approved, we add it to the fix library with an updated version. See the note below for an explanation of our versioning approach. After a Root Patch is put into production, any future image containing the same vulnerability can be remediated instantly during AVR.

📘

Note

See here for an explanation of how Root handles naming and versioning of patches.

Root Patches in Production

Newly approved Root Patches are continuously added to the fix library, creating a flywheel effect—any future occurrence of the same vulnerability can be automatically remediated during AVR without additional manual work. If a previous scan flagged a package as having no available fix and a Root Patch is now available, it will be automatically included in your next build—bringing you one step closer to near-zero vulnerabilities.

Future remediation scans will always draw from our full inventory of patches, both those discovered in the wild and those created by our expert teams.

Details of the use of Root Patches are clearly visible across the admin portal, with key fields such as image name, remediation summary, and package version changes clearly displayed, and you can even review the actual code changes.