Michael Cembalest’s excellent analysis of “Patchmageddon” describes how the gap between the speed of vulnerability exploitation and the speed of remediation started growing well before the AI era, and is now accelerating.
Software increasingly relies on open source libraries maintained by a relatively small number of people, while the time between vulnerability disclosure and exploitation has collapsed. In many cases, exploitation now happens before or on the day of disclosure.
AI makes this imbalance worse. Attackers can use AI to discover and exploit vulnerabilities faster, while defenders still have a human bottleneck: someone needs to investigate the finding, understand the code, decide how to fix it, make the change, test it and get it merged. For open-source software with downstream applications that depend on the vulnerable component, someone must then upgrade to the fixed version without breaking changes.
The report points to tools like Codex Security and Claude Security as an important part of closing this gap.
I agree with the problem statement, but I think remediation speed alone is only part of the solution.
Patchmageddon is an engineering problem.
At Cycode, we split it into two problems that need to be solved together:
- Burn down the existing vulnerability backlog.
- Close the loop so we stop creating the same vulnerability patterns again.
If you only do the first, you are trying to empty a bucket while it is still filling.
If you only do the second, you still have years of accumulated vulnerability debt sitting in production which AI is getting better at identifying and exploiting.
You need both.
Backlog Burning
The first part of the problem is changing the unit of remediation.
The traditional workflow treats every vulnerability as an independent unit of work: investigate it, create a ticket, fix it, review it, merge it, and then start again. That model does not scale. Instead, remediation should be organized around the actual unit of change.
A single base image upgrade can remove dozens of container CVEs. One dependency update can resolve several SCA findings. Multiple SAST findings in the same file can often be handled in the same pull request.
This is where context matters. Cycode’s Context Intelligence Graph connects findings back to the code, dependencies and infrastructure that produced them. That lets us group remediation work by file, package, Dockerfile, repository or other shared context instead of treating every vulnerability independently.
AI can then reason about the entire group, determine the changes required and generate a coherent fix, while reachability, exploitability and other context help decide which groups should be addressed first.
But generating or merging a fix is not the end of remediation. A remediation is complete when the fix is deployed and the affected exposure is verified as resolved. That means the workflow needs to follow the change all the way from finding, through remediation and deployment, to validation that the vulnerability is actually gone.
The principle is simple: correlate security signals to root causes, automate as much as possible, and optimize engineering effort to eliminate the most vulnerability debt.
Prevention
Burning down the backlog is only half of the problem.
Coding assistants are strongly influenced by the code, examples, conventions and instructions they are given. That can work against you or in your favor.
If your codebase contains the same insecure implementation in dozens of places, and you do nothing about it, coding assistants can continue producing code that follows the same pattern. As developers write more code with AI, you can end up reproducing those mistakes faster as well.
But the same mechanism can be used in the opposite direction.
When you find a recurring vulnerability, fixing the existing instances should only be step one. The next step is to understand the pattern behind it and encode what you learned back into the development process.
Traditional AppSec scanners are largely built around static rulesets: the same rules are applied across thousands of organizations, regardless of how a specific company structures its software or what patterns actually cause vulnerabilities inside its codebase.
At Cycode, we use AI to make those rules specific to the organization or repository. AI can look at the vulnerability patterns already present in the code, understand the APIs, frameworks and conventions behind them, and adapt existing rules or create new ones to catch those patterns in the future.
For recurring patterns that can be reliably expressed as rules, we do not need an LLM to rediscover the same mistake on every pull request. AI can learn from the vulnerabilities we find and help create or adapt the rule, while validated deterministic checks enforce that pattern consistently from that point forward.
Not every vulnerability fits that model. Agentic analysis plays an important role in investigating vulnerabilities that require deeper contextual reasoning, while deterministic scanning handles the patterns we already understand well enough to encode.
And we can close the loop on the generation side as well.
The same lesson can be added to the instruction files and context used by coding agents — CLAUDE.md, AGENTS.md, Copilot instructions, Cursor rules, or whatever the development environment uses — so the assistant knows the correct way to implement that pattern before it writes the code.
For example, if teams repeatedly use an internal authorization API incorrectly, you do not want to keep fixing that same issue every time it appears. You want to educate the developers and influence the coding agent to prevent the issue in the future.
Fix the existing instances.
Use AI to create or adapt a deterministic rule that catches the incorrect usage.
Then teach the coding assistant the correct way to use the API.
Now the vulnerability you found in production changes both what the scanner rejects and what the coding agent produces.
Closing the Loop
This is where backlog burning and prevention become one system.
You find vulnerabilities.
You group and remediate them around the actual engineering change.
You look for the recurring patterns behind those vulnerabilities.
AI turns those patterns into organization-specific detection rules.
Deterministic scanning enforces them.
And the same knowledge is pushed into the rules and context used by coding assistants so they stop producing the same mistakes.
Then you look at what still gets through and repeat the process.
Find → Fix → Learn → Prevent → Repeat.
Over time, you are doing two things at once: reducing the existing vulnerability backlog and reducing the rate at which new vulnerabilities are added to it.
That is very different from how vulnerability management traditionally works.
Today, most organizations continuously discover vulnerabilities, add them to a backlog and then try to prioritize and remediate them faster than new vulnerabilities arrive.
AI makes that model increasingly difficult to sustain.
But it also gives us an opportunity to change it.
Instead of treating every vulnerability as another ticket to close, we can treat it as information that improves both the security controls around the code and the way the next piece of software is written.
That is why Patchmageddon is not inevitable.
The attacker advantage is real. The amount of software being created is growing quickly. And the time available to respond to vulnerabilities is getting shorter.
But this is still an engineering problem.
Burn down the vulnerability debt you already have by organizing remediation around the highest-leverage changes.
Then take what you learn from those vulnerabilities and feed it back into both sides of the development process: teach the scanner what to reject, and teach the coding agent what to produce.
Do both, and you stop running the same remediation race over and over.
You start building a security development cycle that improves itself.
