Patching Legacy Code When AI Is Finding the Vulnerabilities

Most IT teams have at least one application nobody wants to touch. It runs, it carries real work, and the last person who deployed it is not sure the build would still succeed. For years that was a maintenance problem. As AI-assisted tools get better at finding vulnerabilities, patching legacy code becomes a question about speed: when someone finds a flaw in that application, how long until a fix is running in production?

The answer depends less on how old the code is than on what surrounds it. An old system with a working pipeline, real tests and a rollback plan can be patched in an afternoon. A newer system that only one person knows how to deploy cannot.

The short answer: treat “can we ship a patch to this system today?” as the security question for every application you still run. Answering yes takes five things: an inventory of what the system depends on, a pipeline that can build it from source today, tests that make a quick change safe, a deployment you can roll back, and engineers who can judge what a finding means. None of that requires a rewrite.

Finding Vulnerabilities Got Cheaper

AI vulnerability discovery is no longer a research curiosity. In the final round of DARPA’s AI Cyber Challenge, announced in August 2025, the competing automated systems analyzed more than 54 million lines of code, found 18 real vulnerabilities that had not been planted for the competition. Across the competition, the systems submitted patches in an average of 45 minutes.

That capability is not limited to defenders. When CISA replaced its known-exploited-vulnerabilities directive in June 2026, its Binding Operational Directive 26-04 gave the reason plainly: threat actors’ “use of AI may further narrow the time defenders have to react between patch release and possible exploitation.” The directive sets remediation urgency by whether a system is exposed, whether the flaw is in CISA’s Known Exploited Vulnerabilities catalog, whether exploitation can be automated, and how much control it gives an attacker, with the shortest window three days.

It binds federal civilian agencies, not private companies. It is still a useful signal of where the clock is heading for everyone else.

Medium Findings Add Up

Severity scores encourage a comfortable habit: fix the criticals, schedule the highs, and leave the mediums for a quiet sprint that never comes. The scoring system itself warns against reading too much into a single number. The CVSS user guide says it “is designed to classify and rate individual vulnerabilities,” and adds a separate section on chaining, where several are used together in one attack.

That is where cheap discovery changes the math. A medium-severity information leak, a medium-severity weak permission check and a medium-severity outdated library can each look tolerable on their own. Together they can be a path into the system. Tools that can read a whole codebase quickly may be well suited to finding those combinations, and a backlog of mediums is exactly the material they work with.

Why Legacy Applications Carry the Exposure

Security attention tends to follow active development. The application your team ships every week gets scanned in its pipeline, its dependencies get bumped, and its owners notice when something breaks. The application that has not had a release in three years gets none of that, because there is no release to attach it to.

So the exposure collects in the systems nobody is actively changing: the internal portal on an old framework, the integration service that still runs on a server someone set up by hand, the vendor-customized application whose build only works on one laptop. Their code may be no worse than anything else you run. What they lack is a way to change it quickly.

That is why a legacy application security plan that starts with a scanner usually stalls. A scanner that reports 40 findings in a system you cannot redeploy has produced a backlog, not a fix.

Find It in Minutes, Patch It in Minutes

A useful target to hold up against every system you run is this: find a vulnerability within minutes and ship the patch within minutes more, routinely and mostly automated. It is a target to work toward, and the exact numbers matter less than the shape. Finding is getting faster on both sides. The half you control is the patch.

Put the target to each application as a plain question: if a credible finding landed this morning, could we ship a fix today? For a lot of older systems the honest answer is “we would have to find out,” and that answer is the risk. A response that starts with rediscovering how to build the application is no better than a response to a zero-day, however early the finding arrived.

What Shipping a Patch Today Requires

Vulnerability remediation for an old system comes down to five capabilities. Each can be built without replacing the application.

1. An inventory and a dependency graph. You cannot patch what you cannot find. Know which applications you run, what each one depends on (frameworks, libraries, runtimes, the operating system, the services it calls), and which versions are in production right now, not which versions the documentation says.
2. A pipeline that builds from source today. If producing a release means a specific machine, a specific person and a half-remembered sequence of steps, that is the first thing to fix. A patch should go from a commit to a deployable build without anyone reconstructing the process.
3. Tests that make a quick change safe. Nobody ships a same-day patch to a system they are afraid of. For older code, start with characterization tests that record what the system does today, odd cases included, so a fix can be checked against current behavior in minutes.
4. A deployment you can roll back. Speed is only safe when undoing it is fast. A patch that cannot be reverted becomes a reason to wait, and waiting is the exposure.
5. Engineers who can judge the findings. AI-assisted tools produce findings; deciding which ones are real, which combine into something serious, and what the safest fix is still takes experienced engineers. That is not work you can hand to a junior developer with a button.

The order matters. A team that buys the scanner first and the pipeline later is likely to spend months triaging findings they cannot act on. Building the path to production first means every finding after that has somewhere to go.

Build as if a Server Will Disappear

Netflix offers a practical model for this mindset. Its open-source Chaos Monkey randomly terminates instances in production, so engineers have a standing reason to build services that keep running when a piece fails. The broader practice, chaos engineering, is defined as “the discipline of experimenting on a system in order to build confidence in the system’s capability” to withstand turbulent conditions.

You do not need to start killing production servers to borrow the idea. Ask a smaller version of the same question: if this server disappeared tonight, could we rebuild it from what is in source control? A system that can be rebuilt from scratch on demand is also a system that can be patched on demand. One that cannot is fragile in both directions.

Where to Start

Pick the application that worries you most and run a patch drill. Make a harmless change, such as a version string or a log message, and take it all the way to production through whatever process exists today. Write down every step, every person involved, and every place it stalls.

Then measure it. DORA’s delivery metrics give you names for the two numbers that matter most here: change lead time, from commit to running in production, and failed deployment recovery time, how long it takes to recover when a deployment goes wrong. Those two numbers are your patch speed. Improve the slowest step, rerun the drill, and move to the next system.

Once a system can be patched quickly, modernizing it gets easier too. The tests, pipeline and rollback you built for patching are the same safety net that lets a team modernize a legacy system without a rewrite, one piece at a time.

Frequently Asked Questions

Does AI-assisted vulnerability discovery mean we need to rewrite our legacy applications?

No. The risk is the time it takes to ship a fix, not the age of the code. Most older applications can get an inventory, a working pipeline, characterization tests and a rollback plan while they keep running, and those are what make same-day patching possible.

Should we fix medium-severity vulnerabilities as urgently as critical ones?

Not every medium needs a same-day fix. Look at mediums together rather than one at a time, and ask whether several of them in the same system could be combined. Exposure to the internet, inclusion in CISA’s Known Exploited Vulnerabilities catalog, and whether exploitation can be automated are better guides to urgency than a severity score alone.

What is the first step if nobody knows how to deploy an old system?

Run a patch drill. Push a harmless change through to production and record every step. It turns “we would have to find out” into a written process and a list of specific things to fix.

The Bottom Line

Finding vulnerabilities is getting cheaper for everyone, and that will not reverse. What you can control is how quickly a finding becomes a fix in production. For legacy code, that is less about the code than about the inventory, pipeline, tests, rollback and people around it.

If you want a clear picture of how fast your team could ship a patch today, our three-week DevOps and CI/CD assessment maps how code gets from a commit to production, including builds, tests, deployment and rollback, measures DORA’s original four delivery metrics from your own data, and ends with a ranked plan your team can carry out. If your roadmap is already full, we can also work alongside your team as an engineering partner for IT teams. Start a conversation about the system that worries you most.

Clear Function is a Memphis-based software development partner that combines strategic advisory with hands-on engineering.