Sam Altman says we can no longer patch all the bugs. He is right. But the answer is not to stop patching. It is to get much better at deciding what to patch, and to make fixing it nearly free.
Speaking at Stanford Graduate School of Business last week, Sam Altman said: "I no longer think we're going to be able to just patch all the bugs."
His reasoning was simple. AI models are getting very good at finding vulnerabilities, and defenders have not kept up. After Anthropic's Mythos announcement, he said, "people definitely patched some bugs," but they "didn't really intuit the exponential." His proposed answer was to "completely switch the defense model to using the same technology."
I agree with the diagnosis.
I also think the most important part of the answer is still missing from the conversation.
Security teams were already living in this world
Whenever I speak with security leaders, the question I hear is not "how do we find more vulnerabilities?" Nobody is asking for that.
The question is: "We already can't fix what we have. What happens when there is ten times more?"
That was true before frontier models started finding bugs at scale. Backlogs grew faster than teams could work them down. SLAs slipped quietly. Engineering teams learned to treat security tickets as background noise.
Altman's remark is not a new problem. It is an old problem that has just become impossible to ignore.
Patch everything was a very rational strategy at the time
It is worth being fair to the approach that is breaking.
For most of the last two decades, "patch everything above a severity threshold" was a reasonable policy. Scanners produced a manageable volume of findings. CVSS gave a shared language for urgency. A dedicated team could triage by hand, file tickets, and chase owners.
The model assumed that discovery was the scarce resource. Finding a real vulnerability was expensive, so every one you found deserved to be fixed.
That assumption is now false.
Discovery is getting cheap.
Fixing is not.
Every patch still needs someone to understand the code, write a change, get it through review, keep the build green, and ship it without breaking production. Engineering time did not get ten times cheaper because models got better at reading code.
And even if you hand the fixing to AI as well, the math does not close. There are simply too many vulnerabilities to patch them all, even with frontier AI models like Claude Opus 5.5. Every fix still costs compute, review time and a deployment, and the number of findings keeps growing faster than any of those.
More discovery without more execution makes things worse
Here is the counterintuitive part.
If you point a better model at your codebase and do nothing else, your security posture can get worse, not better.
More findings land in the same queue. The real issues get buried under the theoretical ones. Engineers who were already ignoring alerts start ignoring more of them. The backlog grows, and the backlog itself becomes the risk.
We see the noise problem in our own production data. Across 14,847 SAST findings triaged over 90 days, 57% turned out to be false positives. That means more than half of what a naive pipeline would hand to an engineer was never worth their time.
The point is not that scanners are bad. The point is that the volume of raw findings was never the right measure of security work. A stronger model makes that volume larger, which makes the gap between finding and fixing wider.
So when Altman says the defense model has to use the same technology, I agree. But a model that finds bugs is not a defense.
A defense is a system that decides what matters and gets it fixed.
The real question is how to allocate finite remediation capacity
If you can't patch everything, the question is no longer "how do we fix all of it?"
It is: which vulnerabilities deserve your engineers' time this week, and how cheaply can each fix be delivered?
That is an allocation problem. Answering it well takes three things.
Decide what is actually exploitable in your environment
Severity is an abstract property of a bug. Priority depends on where that bug lives.
The same SQL injection might sit in an internal admin tool behind a VPN in one service, and in a customer-facing login flow in another. A CVSS score treats them identically. Your attacker will not.
Prioritization has to account for reachability, exploitability and business context, not just raw severity. It also has to move with the threat landscape. When a technology you run is being actively exploited, it should jump the queue that day, not at the next quarterly review.
Prove it before a human has to look at it
The scarcest resource in a security program is the attention of the people who can fix things. Every finding you hand them without evidence spends some of it.
Where you can exploit a path, do it, and show the request and response. Where you can't, validate reachability and context before the finding reaches anyone. Engineers act on proof. They learn to ignore guesses.
Make the fix the default, not the ticket
This is where most of the work in Altman's new world lives.
If finding a bug costs a few dollars of compute and fixing it costs a day of engineering time, the economics only work if the fix gets dramatically cheaper too. That means the system does not stop at a ticket. It writes a minimal, root-cause change, checks it against the build and tests, opens the pull request, and keeps working on it through review.
Backlog in. Fixes out.
This is what we built Nullify to do
Nullify is an autonomous product-security system built around this allocation problem. It turns validated risk into merge-ready fixes.
In practice, that looks like this:
- One prioritized backlog. Security Program Management brings code vulnerabilities, leaked secrets, cloud misconfigurations, supply-chain risks and validated pentest findings into a single backlog. Each item is scored 0–100 on severity, exploitability, reachability and business impact, not raw CVSS. Actively exploited vulnerabilities and zero-days affecting technologies you use move up automatically.
- Noise removed before review. Triage and Remediation filters unreachable code, test fixtures and benign configurations, and re-triages automatically when code, dependencies or threat intel change.
- Proof, not guesses. Our pentest agent continuously attacks REST and GraphQL APIs, and exploit validation attaches request and response pairs, screenshots and video to what it confirms. Secrets detection tests candidate credentials against the real provider so live secrets rank above dead ones.
- Fixes, not tickets. Autofix writes a minimal, root-cause change, validates it against the build before the pull request opens, then reads CI output and fixes failures through review.
- Campaigns instead of queues. Security leaders set objectives such as "eliminate leaked secrets" or "upgrade CVE-affected dependencies," and Nullify routes the work to the right owners based on CODEOWNERS, commit history and current workload.
In other words, we use the same technology Altman is describing. We just point most of it at the part of the problem that was always the bottleneck: execution.
The wrong takeaway is to automate everything
There is a tempting reading of "you can't patch everything" that I think is dangerous.
It goes like this: if humans can't keep up, take humans out of the loop. Let the AI find the bug, write the patch and merge it.
That is not what the problem calls for.
Flooding a repository with machine-written pull requests just moves the backlog from the security queue into the review queue. Merging them unreviewed trades one kind of risk for another.
So we made two deliberate choices. Nullify never auto-merges. A human approves every change. And we cap throughput at three open fix PRs per repository and five per remediation plan, so engineers get a steady flow of reviewable work instead of a wall of it.
The goal is not to remove people from security. It is to spend their attention only where it changes the outcome.
Stop trying to patch everything
Altman framed this as a warning, and it is one. The volume of discoverable vulnerabilities is going up, and it is not coming back down.
But the security leaders I talk to do not need another reason to feel behind. They need a different question.
Not "how do we patch everything?"
"How do we make sure the right things get fixed, fast, every week?"
Answer that, and the volume stops being the threat.
You can't patch everything. You can patch what matters.
