Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit Speed. So?

Many years ago while at Gartner, I wrote a blog post where I defined the concept of the “Patch Sound Barrier.” (original via Archive if you don’t believe that I was that smart back in 2013 :-)) This was an idea of a maximum speed that a given organization could fix a given vulnerability. If you full throttle beyond that, the engines will whirr louder, but the plane won’t fly faster, essentially.

The discussion arose from people constantly asking about the “optimal” or “desired” speed of patching. In my time as an analyst, I reviewed plenty of policies as well as “operational practices” (which is what people call it when they don’t actually follow their own policy “because reasons” :-)). BTW, I utterly hated “30 days flat” policies that say that vulnerabilities are fixed within 30 days no matter what, and always steered people to more nuanced risk-based policies.

One concept emerged: Given a particular IT environment, there is often a maximum physical speed at which an organization can patch. That is my Patch Sound Barrier.

Why bring this up now? Because the speed of vulnerability discovery is accelerating and so does exploit dev speed, but for many organizations, the speed of remediation simply cannot be accelerated. It is not accelerating, because it cannot. Full stop.

In the past, my guidance was to focus on better vulnerability prioritization so that you fix “real risks” using CISA KEV, EPSS, CVSS (OK, maybe not in the 2020s) and various tools that analyze the data and give you a ranked list.

But today we will have more vulns and prioritization tools won’t save you. If you have 1,000,000 vulns and 1000 are “risky for you” (however defined, let’s say you have the magical tool that reveals the true and real risk for your organization … ha), you can reduce the risk enough by fixing the 1000, if you have the bandwidth to fix the 1000 (in theory). Now, imagine you have 10m vulns (thanks AI!) and say 5000 are risky. But your bandwidth is there to only fix the 1000. So your risk goes up anyway, while you work as hard as before.

Now, you might say, “Anton, you’re making absolute statements. Surely things are flexible given enough money, enough talented engineers, and these days, enough LLM tokens?”

This is true in theory. But notice I said, “given the IT environment.”

There are definitely methods for accelerating remediation in a modern, beautifully and carefully designed environment (check our podcast episode 109 for those ideas).

But let’s review the scoreboard:

• The speed of vulnerability discovery? Increased.
• The speed of exploit development? Increased.
• The speed of remediation in legacy environments? Unchanged.

OK, some of you might still think “cannot” is too harsh. But people at modern organizations — all DevOps, CI/CD, open source and now AI agents — sometimes cannot comprehend what it takes to deal with a 1990s-era “DBA from Hell” who views his beloved database as a pet, not cattle, and will only allow a patch twice a year on a rigid schedule. Don’t even get me started on OT or the sea of unpatched edge appliances out there (there are “forti” millions of them there, I hear …)

So, yes, I spent years providing recommendations on how to deal with this “vulnerability flood.” This isn’t just about the current fascination with AI; at one point, the “boogeyman” was Metasploit, or something else. Or, as old people told me, SATAN / SANTA in the mid-1990s.

The fact remains: there are more risky vulns than you have time / capability. Today. AI can find the bugs in milliseconds, but it still can’t convince a legacy middleware admin to reboot a production server on a Tuesday. Or in July. Or in 2026. Or this freakin’ century …

So far it sounds like a rehash of my past ideas, but I actually want to leverage some thoughts from Phil Venables’ blog series about speed (“Things Are Getting Wild: Re-Tool Everything for Speed” and “Cybersecurity’s Need for Speed & Where To Find It”)

Before we go there, we must remember about reducing risk without remediating vulnerabilities. This was often the most insightful bit I shared with clients back in my analyst days: Sometimes your focus must be on reducing your risk, rather than fixing the bug. Kinda “assume the breach”, but for vulns: “assume you can’t patch” then what?

So, how do you get speed to break through the sound barrier (alert: these do NOT apply to everybody):

• Brutally destroy legacy systems; if it cannot be patched quickly and safely, don’t use it. Think “SaaS and Chromebooks” (and cloud) world. Don’t think 1980s ERP crap.
• Modernize. Kill pets. Grow cattle. Ideally, get replaceable tiny insects as cattle. They are simpler, more replaceable and less cute. Think “pets -> cattle -> insects.” [P.S. I do not recall where I got this idea, if I stole this from you, I am sorry — happy to restore credit if you tell me]
• Evolve IT culture to accept automatic patching, everywhere. If Chrome can autopatch 1b systems safely for 10 years, perhaps there is a way to do it, eh?
• Eliminate the risk entirely (e.g., via micro-segmentation or data avoidance) when patching is impossible. If you cannot remove the vuln, remove the connection, the system or the entire business process.
• Shift focus from patching to overall IT lifecycle velocity by decoupling the application from infrastructure. In faster IT, patching is faster. Fight friction, just like you fight toil.

These are some ideas on how to shift from “floor the gas” to “build a supersonic plane” to break the patch sound barrier! Are you still debating patch cycles, or are you architecting your way out of the need for them? Please share more!

Enjoy … living in interesting times!

Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit… was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

OK, RSA 2026 is over. If my record keeping is correct, I first attended RSA in 2006. At that time, I was annoyed by … AI? XDR? NIDS? …. noooo… I was annoyed by NAC (“As many other RSA observers agreed, under each tree you now see a NAC.” NAC rapidly arose from the “wormy” early 2000s and quickly vanished inside network infrastructure devices).

Anyhow…

If the RSA Conference is the annual, sprawling theme park of the cybersecurity industry, then RSA 2026 was the year the park owners unveiled the shiny, terrifying, and utterly bewildering “AI Rollercoaster.” But as my co-host Tim Peacock and I sniffed around the expo floor, a familiar suspicion crept in: half the queue signs were blatant fabrications, and the ride itself might only be half-built.

For decades, we’ve attended this annual security pilgrimage expecting consolidation, disruption, and an industry growing up. And every year, we leave with the same truth: the more things change, the more they stay the same (and no, I am not old enough to be called “a curmudgeon”). This year, the force of AI agents was everywhere, yet the industry’s response — the good, the bad, and the baffling - revealed more about our collective inability to do the fundamentals than it did about the technology itself.

The first thing you notice about the AI Rollercoaster is the marketing. It’s less about engineering excellence and more about colorful claims that would make a 1890s snake oil salesman blush. Our first, unavoidable observation was the sheer breadth of the AI Hype Spectrum, a problem of which AI washing is one of the levels.

We saw vendors across the spectrum: from those quietly using AI for genuine, impactful security tasks to those who merely “spray painted an AI” onto their 2021 marketing materials and called it a new platform. This latter group — the “AI touch-up” artists — are everywhere, simply adding a comma and the word “agents” to their identity management tools description, firewalls, anti-virus and calling it a day (I have booth pictures, yes)

Look, you are not an AI native company if you launched in 2003 and have a “talk to docs / manuals” chatbot in 2026. BTW, your chatbot can be easily convinced to spout political propaganda because your RAG sucks and you think “restrict via system prompt” is AI security…

This brings me to the first core truth of RSA 2026: to succeed, the buyer must be the expert. It is profoundly disappointing — though not surprising — that in an industry claiming to be on the cusp of a technological revolution (AI AI AI!), our most potent advice for a CISO is a throwback to the days of dial-up: due diligence. BTW, see this quote: “The problem is that most of the people attending the RSA Conference can’t understand what the products do or why they should buy them.” This is…. OH HORROR! .. Bruce Schneier in 2008.

The genuine use of AI in a product is now almost entirely disconnected from the glossy message on the vendor’s booth. You, the buyer, need to dig deep, get technical, and understand what they are actually selling. If they claim AI makes their firewall (or: your SOC) better, tell them to show you the numbers (Better how? Better where? By how much? Depending on what?). If they can’t produce data and solid metrics on how AI improved their thing, you must assume they are not credible and are essentially lying. Sorry, but “cloud native firewall” is not a thing.

And speaking of gloss, a related phenomenon was what we called the “Wiz Effect.” We saw a notable rise in whimsical, information-free booths — lots of pinks, purples, superheroes, and non-security-related sports figures. While a tasteful aesthetic is welcome, this strategy only works if you are already a $32 billion company named Wiz. It did work- and it still does work — for Wiz! Wiz can have soup cans in the booth, and it will sell CNAPP by the million. For others, a fantastical booth merely meant your booth was remembered, but your message was utterly lost. Goats! Also, its low-information density approach compounds the problem of AI washing.

In the past, some clowns predicted that our industry will consolidate and only a dozen large vendors will remain. In 2026, many fear a different Vendor Apocalypse where the large AI labs will simply run over existing security vendors. If a massive LLM can run on an endpoint and perform vulnerability analysis, why do you need a standalone vulnerability scanner? To me, this risk is absolutely real, particularly for product categories like Static Analysis (SAST), which seems custom-made for LLM decimation (reminder: I am not an appsec expert). The same logic applies to firewall rule analysis, policy writing, and many simple IAM/PAM decisions. However, it is not yet clear (my gut says “no”, my brain says “wait for RSA 2027, then ask again”) that the entire industry is vulnerable though…

And this is where the industry’s legendary IT inertia kicks in. The persistence of “The Old” is a stunning, annual lesson in the industry’s resistance to disruption. We saw large booths from vendors whose heyday was decades ago — the fifth best firewall and antivirus vendors are still alive and well as if the calendar still shows 2006. Do you believe that Checkpoint sells “AI security”? They do now! Anyhow, they are still collecting hard-earned money from buyers. This proves that the promised AI disruption has not yet killed off even the “number six” player in a market., much less hurt the #1. “Last vendor on the list is … still ON the list” was my insight here.

Why such epic survival skills? I think it comes down to enterprise knowledge and IT inertia. We debated whether the security industry would survive based on the same concept that keeps human analysts relevant against a giant LLM: the possession of “tribal knowledge.” This is the accumulated, aggregated, and integrated gossip … eh … customer data…that good security vendors hold about their clients’ specific environments. This tacit knowledge, the context of why things are done, is not public, and an AI robot won’t have it today (theoretically, there are ways for them to gather it, to be sure). If your security operation relies on this copious chunk of tribal knowledge, a super-intelligent chatbot won’t replace your vendor — at least not yet.

Another odd observation here. For some vendors, promoting “openness” seems like a signaling maneuver for weakness, not strength. We walked past booths proclaiming “open data lake,” “open detection,” and “open ecosystem.” While I believe openness has inherently positive value, my cynical analyst brain immediately wondered: are they more open or are they just not better? See, vendor A sells EDR, and it is really good. Vendor B EDR sucks compared to vendor A. So they market it as “open EDR” because they cannot market it as “the better EDR” (it ain’t better, even according to them). Reactions?

While the hype around AI for security was overwhelming, there was a positive and genuinely exciting shift: the rise of securing AI and agents. Last year, I lamented the lack of focus on protecting AI systems. This year, I was pleasantly surprised to see vendors focusing on securing agents, securing agent identity, and doing data security for the AI supply chain and training data.

The third pilar of this is the bad guy with AI. To me, the real fear isn’t the “Bad Guy with AI” or even the coming “Bad AI”; the fear is the acceleration of the inevitable. If your security posture is bad before AI, it’s just going to be bad — and faster — after AI. As attackers modernize their business with AI, the average time to compromise will drop even further and — IMHO more importatny — a chance of a compromise will go up (ref this week suppy chain hits)

The ultimate takeaway here is the “boring” lesson: Get the fundamentals right (and, yes, AI can help here too). No amount of AI from a threat actor will exploit your cloud misconfiguration if you don’t have one (well, either cloud or misconfiguration). If your defenses against misconfigured systems, containers, and instances are robust, it doesn’t matter that the bad guy has AI; your stuff is more secure. The acceleration brought by AI will simply kill off “luck-based security.” The old adage is true: if your app has no obvious exploitable holes, there’s nothing for the AI-armed attacker to find. Magic!

So my single piece of advice for dealing with this reality, whether you are a buyer, a seller, or an analyst, is simple: demand the data. Do not let vendors get away with buzzword bingo. If a vendor says AI helps, make them prove it with solid metrics. The time for “trust-me-bro” security better be over!

Finally, some reactions from my 3 sessions. The most shocking reactions came from my “AI SOC” peer discussion on Thursday. I noticed a shocking, near-total lack of enthusiasm about AI SOC startups (total) and AI SOC concepts (near total). The best I got was “AI in a SOC sounds great, we will just wait for our SIEM/SOAR vendor or MDR to build it” and “this is better SOAR and we want this, but later.” And think about it: this was for people biased in favor of AI SOC (because they showed up for the session)… Not sure yet what to think of it!

Fun takes from other people(and there are many) are here (key quote: “Perhaps I’m being overly dramatic but I was surprised with the generally relaxed tone about the impending wave of vulnerabilities and the extent of industrialized attackers coming in the coming quarters. Everyone seems to know vulnerability management isn’t where it needs to be in most companies and what’s coming will pile on the pressure.”), here, here.

Related blogs:

• Our RSA 2026 recap podcast (EP269)
• RSA 2025: AI’s Promise vs. Security’s Past — A Reality Check
• RSA Conference 2025 Recap Podcast
• RSA (“RSAI”) Conference 2024 Powered by AI with AI on Top — AI Edition (Hey AI, Is This Enough AI?)
• EP172 RSA 2024: Separating AI Signal from Noise, SecOps Evolves, XDR Declines?
• RSA 2023: Not Under the GenAI Influence Yet!
• RSA 2023 — What We Saw, What We Learned, and What We’re Excited About
• RSA 2023 — How to Protect Your Organization from Cyberattacks in Time of Political Turmoil
• RSA 2022 Musings: The Past and The Future of Security
• RSA 2020 Reflection
• RSA 2019: Happily Not Over-AI’d
• RSA 2018: Not As Messy As Before?
• RSA 2017: What’s The Theme?
• RSA 2016: Musings and Contemplations
• RSA 2015: Rise of Chaos!!
• RSA 2013 and Endpoint Agent Re-Emergence
• RSA 2006–2015 In Anton’s Blog Posts!
• My Really Fun RSA 2026 Presentations!

RSA 2026: Agentic Future, Analog Fundamentals — The Paradox of Why the Old Guard Still Survives was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.