← Resource hub
On-demand

Closing the AI remediation gap: find once, fix everywhere

Watch one Spring Security CVE get found and fixed across 75 repositories and 6.5 million lines of code, with the agent writing the recipe instead of editing the repos.

The average security fix takes 252 days. AI models now surface hundreds of vulnerabilities in a single application, at a pace remediation pipelines were never built for. Sam Snyder and Bryan Friedman take one real CVE from detection to verified fix across an estate of 75 repositories.

The challenge

Scanners have gotten steadily faster at finding things, while the work of actually closing a finding still moves at the speed of a review queue. A scan can produce a thousand findings in an afternoon. Draining that queue takes the rest of the year.

Attack and defense are not symmetric here. An attacker needs one instance of a vulnerability. A defender has to close every instance, everywhere it exists, or the business is still exposed. Fixing one repo at a time is what makes that impossible to finish.

What we covered

One CVE, more than one fix. CVE-2026-22732 in Spring Security had no single answer. VMware published open source patches only for the two most recent major and minor lines, so repos already on 6.5.x or 7.0.x could take a patch bump. Everything else needed a paid extended support contract or a code change. Across a real estate, the correct fix varies repo by repo.

A dependency scan won’t tell you whether you patched it in source. Most vulnerability scanners, including find-and-fix-vulnerable-dependencies, look at which version is in use. Once some repos are fixed with a code change instead of an upgrade, you need detection sensitive enough to tell a patched repo from an unpatched one running the same version. Sam wrote a scanning recipe that checks both, so the report stays honest as the fix rolls out.

Size the problem before you start fixing it. The demo ran across 75 open source repositories, 6.5 million lines of code, worked on by 54 developers. A custom DevCenter card sorted them into already fixed, patch bump, minor bump, and major bump, and the whole search reruns in seconds. That is the difference between reporting real progress and having program managers knock on doors asking whether it’s done yet.

Apply and verify across the estate, not one repo at a time. mod git apply --last-recipe-run pushes the generated patches to every affected repository. mod exec then runs each project’s own test task, Maven or Gradle, so failures surface immediately. Anything that breaks goes back into the recipe rather than into a person’s queue.

Use the agent to write the recipe, not to edit the repos. Agents are good at finding vulnerabilities. Pointing one at thousands of repositories to fix them is a different problem. Sam pointed Claude at the vulnerability description and the 75-repo corpus and iterated until the fix held, producing the detection recipes, the DevCenter card, and the fix recipes in about an afternoon. The output is deterministic, testable, and reviewable.

The work compounds. Asked in Q&A whether a recipe is a form of memory, Sam said yes. Anything you encode becomes actionable from that point on, and reusable pieces like dependency and parent POM upgrades carry into the next issue. The hardest repositories are the first ones you do. Everything after that gets faster.

Also covered

  • How find-and-fix-vulnerable-dependencies gets its data. A CI job pulls the GitHub Advisory Database every Monday and embeds it in the recipe module (rewrite-java-security), rather than querying live from thousands of repos at once. Staying on the latest recipe release means staying on the latest database. The source is configurable if you use an internal vulnerability database. Equivalent recipes exist for Python and C#.
  • Sam’s recommended setting: override transitive dependency vulnerabilities, with the maximum upgrade delta set to patch. Conservative, and unlikely to produce breaking changes. The data table still reports everything found, including the findings that need a minor or major bump.
  • The Backpatch Alliance, Moderne’s backpatching product, which produces auditable fixes for critical open source frameworks that are past their end-of-support date.

For the argument behind the demo, see Jonathan Schneider on why agentic coding alone can’t close the remediation gap.