Recently, somebody from a fairly mature security team told me something I did not want to hear: if software vendors run “Mythos-class” models on their own code and fix what they find, they must publish a CVE for every fixed vulnerability.

My first reaction (vendor hat firmly on, since I now work at Cisco) was: huh? Why? These bugs were found by the vendor, fixed by the vendor and were never public. A vast majority (but not all!) are not exploited. CVE CNA rules make assignment a SHOULD, not a MUST, and whether a quietly shipped fix even counts as “publicly disclosed” is something considered debatable. Why would anybody want it?

My second reaction, a bit later in the conversation was: oh, that!

They have a point. Sort of. They were simply describing how their vulnerability management program works. And, I suspect, how many of yours work too. Their problem is about to become everybody’s problem; they just noticed it first.

The Problem In One Sentence

Many VM programs start with a vulnerability scan, not with a patch, a vendor release or … a news headline about a new terrible security issue.

The chain looks like this:

Note what is not on this list: the vendor advisory. It is not an input in their case.

Before anybody snickers or ROFLs about it: this was a sound design for about 20 years. In the 2000s and 2010s, an issue that mattered usually got a CVE (yes, before the “vuln-purists” tear me to shreds, there were some exceptions to this even back then!). And a CVE got a check from your vulnerability scanner vendor, usually within days (in my Gartner days, we called them “Q/R/T” for the reasons you can easily guess…). Auditors want evidence, ticketing systems need an ID, and SLAs need an event that starts the clock. A “scan-first” program is what you get when you optimize for all of that at scale. It is a property of the pipeline, not a failure of the people running it.

So a software or an OS vendor can shout “URGENT, upgrade now!” all it wants. If the fix has no CVE, the scanner (usually) has no finding, there is no ticket, no SLA clock, no change request, and no patch (at the companies that follow that model).

Here are the two paths side by side:

Why This Matters Now: Hello, Vulnerability Apocalypse

I hate the “post-Mythos” label as much as the next person, but these numbers are not marketing. (BTW, every time you say “post-Mythos” for marketing purposes, Claude kills a kitten.)

In Patch Sound Barrier Part 2 I defined the “vulnerability apocalypse” as four things arriving together: massive vulnerability volume, fast exploit development, exploitation at scale and resulting incident damage. Factor #1 is no longer theoretical: high and critical CVEs from notable vendors ran at roughly 3.5x the prior monthly record in June 2026, and at about 5x in July.

Now the twist: those charts only count the fixes that got a CVE. The pile of internally found, internally fixed, never-CVE’d bugs is not on any chart. For scale: Anthropic said in May that Mythos Preview had been used to find more than 10,000 high- or critical-severity bugs, not all of them publicly reported.

That is the part of the iceberg your scanner cannot see (usually). So a big chunk of the AI era’s fixes may be exactly the ones that scan-first programs miss! Your patch SLA dashboard stays green while your actual exposure grows. Green-but-wrong is worse than red.

BTW, “internally found” does not mean “nobody else knows.” Attackers have access to capable models too, AI makes patch diffing cheap, and some vendor advisories now list “internally discovered” bug classes that also contain actively exploited bugs. Found internally means “we found it too,” not “we found it first and only.” Yes, I know, Captain Obvious strikes again, but a scan-first program behaves as if this were not obvious at all.

Timing makes it worse. Here is one real example (via X post): CVE-2026–72529, a remote, unauthenticated script execution bug in TrueConf Server. The issue was found in June, the patch was also released in June, exploitation was spotted in July, and the CVE was assigned in August, by Kaspersky as a third-party CNA, not by the vendor. For a scan-first program, that bug did not exist for about two months, including the month it was being exploited. Note that even the “exploited bugs get a CVE” metric ran a month behind the exploitation here — away too slow. (Yes, it is a niche product. Niche is exactly where scanner coverage is thinnest.)

Who Taught Us to Think This Way?

Naturally, I also asked on X, and I got my share of thoughtful responses like “ask if adversaries will delay exploitation until a CVE and severity score exist”, “FYI, vulnerabilities without CVEs, or with low scores, regularly cause damage” and a reminder that “a CVE reflects severity after discovery, not exploit probability.” All true, all ignored by scan-first vulnerability management programs…

The best answer IMHO was this point: somewhere along the way, “a lookup key [CVE] became a proxy for risk.” Indeed, how did that happen?

“Scan-first” did not appear out of nowhere. Scanner vendors taught the market to think this way, and the market went along happily.

Some of the blame here is well deserved:

• Coverage was sold in CVEs. For years, the headline number in every bake-off was how many CVEs a product detects and how fast a new check ships. Many customers learned that the CVE list is the threat model.
• The CVE became the unit of work. Dashboards, risk scores, SLA reports and ticketing integrations were all built around CVE IDs. Anything without one is a second-class citizen in the product, and therefore in the program.
• “Clean scan” became audit evidence. Compliance scanning made “the scan report is clean” the proof that auditors still ask for. In PCI DSS ASV scanning, pass or fail is largely decided by the CVSS scores of the findings. (Yes, I co-wrote a book on PCI, so I am not innocent here either.)
• Non-CVE coverage exists, but nobody marketed and sold it. Many scanners do have checks keyed to vendor bulletins, and most flag outdated or unsupported versions. In practice, those often land as low-priority findings that no SLA tracks. They were never the thing on the slide…

And before you say “just use KEV and EPSS”: both are keyed on … CVE IDs. KEV only lists vulnerabilities that have an assigned CVE, and EPSS only scores CVEs. “Risk-based” Vulnerability Management built on CVE-keyed inputs inherits the exact same blind spot. Not very risk-aware, that is.

To be fair, all of this was once rational. A CVE is a clean, shared, countable unit, and you can build a product (and a business) on countable units. This worked kinda OK in 2015, worked poorly in 2021, and really, really does not work in 2026.

So a market that was essentially taught “if it’s not in the scanner, it didn’t happen” now needs to learn something new, and the people who taught the first lesson are best placed to teach the next one.

The Three Obvious Fixes Are Suboptimal

CVEs are not only a scanner input; they are also a public accountability ledger. This industry has a long and not very proud history of silent patching, and “trust us, we fixed it, this matters to you” has earned all the skepticism it gets.

At the same time, the vendor-side point also stands. Defenders at software companies will use those models to fix their code, and their code is getting better and more secure. Flooding the market with huge piles of CVEs will not help anybody. Both things are true at once, and that is what makes this problem interesting.

So, the quick fixes, each with a catch:

• Option 1: A CVE for every internally found bug. At AI scale, this floods scanner queues with hundreds of findings that a single upgrade closes. We have actually run this experiment: after the Linux kernel became a CNA in 2024, it started assigning CVEs for thousands of backported fixes, and people have complained about the noise ever since. Even Epoch had to footnote it as noise in their CVE charts.
• Option 2: Bundled CVEs. Cisco now ships scheduled security releases with CVEs bundled by weakness type (CWE), and still assigns an individual CVE when a bug is exploited or needs a compensating control. It is a pragmatic middle path. If a bundle is scored by its worst member, it also pushes you toward handling exceptions per release rather than per CVE, which, as you will see below, is exactly where I think you should end up anyway…
• Option 3: Read vendor advisories manually. Ah, the good old days! Mapping advisories from hundreds of vendors onto thousands of assets by hand does not scale, and frankly never did.

Note that Option 3 is wrong about the how, not the what. The advisory does need to reach your program. A human with a browser and 200 vendor websites just cannot be the delivery mechanism.

So What Would Actually Work? Make the Advisory an Input

In my strictly private opinion, the vendor advisory must become a first-class input to vulnerability management, next to the scan, not behind it. Not “instead of the scan,” and not “if the scanner vendor gets around to it.”

The chain should look like this:

Obviously, better programs do this today, so for a decent percentage of this blog’s readers this should really not be news. This blog is not for you.

Getting there needs three parties to move, not one (plus your auditor):

• Vendors: publish machine-readable advisories (CSAF much?) with fixed versions, urgency and exploitation status. And keep the accountability ledger honest: assign an individual CVE the moment a bug is exploited or needs a compensating control. (Yes, this is close to what my employer committed to in June. This is the easy part; the next bullets are the hard ones.)
• Scanner vendors: you taught the market that the scanner is the source of truth, so you get the first job. Ingest those feeds and create findings under your own IDs, no CVE required, at real severity rather than as an informational footnote. You already flag “outdated version”; this is the same idea, driven by vendor data. (Yes, the risk is that coverage follows market share. Niche OT vendors, I am looking at you.)
• VM programs: add a currency metric next to CVE closure, e.g., percent of assets within N releases of the vendor’s latest security release. In other words, patch the release, not just the CVE. If your remediation speed is capped by the patch sound barrier, spend that limited throughput on upgrades, not on ticket accounting.
• Your auditor: if audit accepts only CVE closure as evidence, nothing above will change. Bring them in early and show them the currency metric before it shows up in an audit finding.

What To Do This Week

Run the 30-minute self-test:

1. Pick your top vendor by asset count (or by internet exposure).
2. Pull their last three security releases and count the security fixes vs. the CVEs. (If the release notes just say “multiple security fixes” with no count, congrats, that is a finding too.)
3. Check what your scanner flagged for those releases.

The difference between what the vendor fixed and what your scanner flagged is your blind spot, in numbers.

Ask your scanner vendor:

• What do you do with a vendor advisory that has no CVE?
• Do you ingest CSAF advisories, and from which vendors?
• What is your median lag from a vendor advisory to a detection?
• Can you show me every asset more than N releases behind the vendor’s latest security release, and at what severity?

Change your program:

• For edge and crown-jewel asset classes, start the SLA clock at the vendor security release, not at the scanner finding.
• Grant exceptions per release, not per CVE.
• Report a currency metric next to CVE closure, e.g., “percent of internet-facing assets on the vendor’s latest security release within 30 days.”
• Put it in contracts: vendors provide machine-readable advisories with fixed versions and exploitation status, and scanner vendors cover non-CVE vendor fixes at real severity.

So?

With my vendor hat on, I still don’t think every internally found bug needs its own CVE. With my VM hat on, it should not matter: your program should not need one to act. Patch the release, not just the CVE. If the gap is zero, congrats, and please tell me how you did it. If it is not, you have found your blind spot… have fun!

Related blogs:

• Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit Speed. So?
• Breaking the Patch Sound Barrier Part 2: So Is The Apocalypse Coming and What Is It?
• Beyond the Vulnerability Apocalypse: Scaling Your Basics and Vulnerability Management
• The 15-Minute Patch, Reverse-Engineered: What Had to Be True?
• Is Vulnerability Management Hopeless? (2019)
• Patch Management — NOT A Solved Problem! (2013)

Rethinking Vulnerability Management: “If It’s Not in the Scanner, It Didn’t Happen” Needs to Go was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Part 2 of the Patch Sound Barrier series, I shared a thought experiment from a talk in May 2026: imagine any vulnerability in your environment can be patched within 15 minutes of release. Now reverse-engineer that reality. What had to be true?

Usman and I revisited this exercise in our “basics at AI scale” post. Readers asked: “How do I actually run this exercise with my team?”

So here’s how. Two ground rules first:

• This is not a 15-minute patch SLA. If you take this post and write “all vulnerabilities remediated within 15 minutes” into a policy, I will find you… I utterly hated “30 days flat” policies as an analyst and “15 minutes flat” is the same mistake with more zeros. The number is a probe, not a target.
• You will never get there across your whole environment. Legacy systems guarantee it. The point is the gap between the fantasy and your reality, because that gap is the most honest map of your program you will ever get. The Patch Sound Barrier is real; this exercise tells you where yours is and what it is made of.

Why 15 minutes, and not “fast”

“Fast” allows cheating. Some consider 90 days “fast” because they started at an annual cadence. “Patch faster” is generic advice everyone agrees with, but rarely acts on (or: barely acts on). An aggressive, specific number forces you to identify which pipeline steps physically cannot fit.

The Cloudflare quote from Part 2 summarizes this: demanding faster patching without redesigning the process leads to skipped steps. If regression testing takes a day, a two-hour SLA just skips testing. This exercise targets pipeline design, not raw speed. A 15-minute window leaves room only for automated steps. Everything else itemizes your sound barrier.

The 15 minutes, minute by minute

Assume a patch drops at T+0. At each stage, ask:

1. What must be true for this stage to fit the timeframe?
2. What is current reality, and what is the gap?

Details:

and

A 15-minute timeline leaves zero room for manual deliberation. In this model, humans define policies, build automation, and handle (rare!) exceptions. They do not manually approve or execute patches.

The five things the exercise refuses to let you skip

1. Inventory as a live graph. If identifying affected systems takes hours, downstream automation cannot compensate. First move: measure how long it takes to locate a specific library or version today. That duration is your baseline gap. Most organizations are shocked. Log4j much?
2. Rapid automated testing. Manual testing blocks rapid remediation. First move: time how long it takes to get from “patch available” to “confident it won’t break prod” on core systems, then work out what it would take to make that 5 minutes.
3. Replaceable infrastructure. Rapid patching relies on redeploying updated templates rather than patching running instances. First move: determine your “replaceability ratio”: the percentage of systems that can be automatically rebuilt from source fast enough to fit the deploy window.
4. Pipeline-level governance. Per-change approval gates prevent rapid execution. Approve the policy and the pipeline, not each patch. First move: transition low-risk change classes to pre-approved automated pipelines.
5. Rehearsed rollback. Teams patch slowly because they fear breaking prod, and they fear it because they’ve never practiced un-breaking it. First move: execute and time an intentional rollback on a non-critical production system.

The cheat code: change the verb from “patched” to “non-exploitable”

For legacy systems, OT networks, or appliances you can’t modify, 15-minute patching is fiction. So change the verb: make the vulnerability non-exploitable or harmless within 15 minutes. That’s the Part 1 move: assume you can’t patch, then decide what you’ll do instead.

The difference (reminder for most, new for some...):

• Patching eliminates the flaw. It requires vendor fixes, testing, deployment, and mutable target systems, factors largely outside your immediate operational control.
• Mitigation reduces exposure risk. It relies on controls you own (network segmentation, identity policies, access gateways … at times an ax) without modifying target code, so actions can be pre-engineered and pre-approved easier.

The 15-minute mitigation exercise tests four capabilities:

1. Can you isolate network paths immediately via automated policy?
2. Can you revoke or scope down credentials in minutes?
3. Do you know the blast radius well enough to isolate a component without breaking the business?
4. Can you push a protection rule via API in minutes? (See API or Die.)

Your patch clock partly belongs to the vendor (partially). Your mitigation clock is all yours. For legacy, that’s the only 15-minute clock that matters.

But a segmentation diagram is not segmentation, and a kill switch nobody has pulled is a hypothesis. As I argued in Survival of the Basics, a mitigation counts only if it is a tested, operational control.

How to actually run this with your team

Book 90 minutes, a whiteboard, and the right people: platform/infra, an app owner, whoever runs change management, and QA. Security alone will find the gaps, but won’t own any of them.

1. Select three specific target systems: modern (containerized service), median (standard application server), and legacy (high-risk core system).
2. Map the clock for each system: document stage durations and identify the gaps.
3. Identify the primary bottleneck stage.
4. Define a single corrective move for that bottleneck: one bottleneck, fixed end to end (same logic as Baby ASO).
5. Apply the mitigation model to legacy targets: establish rapid containment controls where patching is impossible.
6. Track stage durations quarterly: progress shows up as shorter stages on your critical systems.

No time for a workshop? Pick a widely used component (a core library or agent) and time how long your team takes to find every active instance with high confidence. That’s your T+0 to T+1 baseline.

So, will you get to 15 minutes?

Containerized microservices can get there (yes, really, but provided some moons are aligned just right). Standard application servers can perhaps go from weeks to hours. Legacy systems need rapid mitigation (segmentation, credential scoping, containment) rather than patching.

What do you think? Is this totally crazy or what?

Related posts and resources:

• The original “patch sound barrier” post (2013)
• Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit Speed. So?
• Breaking the Patch Sound Barrier Part 2: So Is The Apocalypse Coming and What Is It? (this defines the “vulnerability apocalypse” term)
• Beyond the Vulnerability Apocalypse: Scaling Your Basics and Vulnerability Management (with Usman Chaudhary, July 2026)
• Survival of the Basics: Which Security Fundamentals Were Secretly Relying on Lazy Attackers?
• Stop Building a 2003 SOC with AI, Part 3 (“API or Die”)
• Baby ASO: A Minimal Viable Transformation for Your SOC

The 15-Minute Patch, Reverse-Engineered: What Had to Be True? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Developed together with Usman Chaudhary @ Google for Public Sector (his post)

Let’s call it what some in the industry are calling it: the vulnerability apocalypse. For years, finding vulnerabilities was slow, expensive, specialized work. LLMs made it cheap — in its first weeks, one frontier model surfaced more than 23,000 issues across a thousand open-source projects, including a 27-year-old flaw in OpenBSD found for under $20,000 in compute. And when finding bugs gets cheap, attackers find more of them — and likely exploit more of them, faster than defenders can patch. This isn’t hypothetical: Google’s threat intelligence team has already reported the first zero-day exploit built with AI, caught being used in the wild. The deluge is real, and it’s here.

Breaking the Patch Sound Barrier: Your Vulnerability Remediation Will Not Keep Up With AI Exploit…

Since Mythos, AI-powered defenses have emerged just as fast: autonomous agents that find and fix vulnerabilities in source code, tools that rewrite code to eliminate whole classes of bugs, frontier models utilized by defenders.

But here’s what gets lost in the arms race: the fundamentals are more important now than they have ever been. When you can’t out-find or out-patch the machines, what saves you is the boring, durable work done well — knowing your environment, limiting how far a break-in can spread, fixing root causes. AI raises the ceiling on both attack and defense; it doesn’t change what good defense is made of. And defending against AI-speed attacks doesn’t always require AI — sometimes it just requires the fundamentals, done well at scale.

One new note to add. Recent incidents like this made some people state that “basics don’t matter, machines will find a way.” To me it means that basics do matter, but consistency and scale are MUCH more critical. After all, and this is a silly example, no machine can find a buffer overflow if you code in Rust. And, yes, sadly, this means you need to be “near perfect”, but hey good news — with the same machines you can. So this is not a boring “do the basics please” post, this is a reminder that you need to scale them with AI.

Why the urgency is real (and different this time)

Why act now, if you’ve heard “do the fundamentals” for twenty years? Because the gap between discovery and exploitation is effectively gone — according to some sources, high-severity flaws are now exploited within hours, sometimes before a public proof-of-concept exists, and the damage is material, widespread, and accelerating.

A program that assumes days or weeks to respond was built for a world that no longer exists. The fundamentals — visibility, segmentation, process — are what absorb the shock when patching inevitably falls behind. And this holds whether AI capabilities jump or improve gradually: the actions needed today are largely the same.

AI made finding vulnerabilities cheap. The attackers noticed. The answer isn’t panic — it’s the fundamentals done well at scale.

Breaking the Patch Sound Barrier Part 2: So Is The Apocalypse Coming and What Is It?

Start by reverse-engineering the impossible

Before any playbook, one exercise — because it does more to find your real gaps than any framework will.

Imagine you could patch any vulnerability within 15 minutes of its release, as if by magic. Now work backwards: what would have had to be true? You’d need to know instantly what you run and where it’s exposed. You’d need testing so automated that a fix ships safely in minutes. You’d need no legacy that resists change, and an architecture built to absorb it. You’d need to have already eliminated whole classes of bugs, so there were fewer to patch at all.

You will never hit 15 minutes across the environment — legacy systems guarantee it. But the gap between that fantasy and your reality is the most honest map you will ever get of where your program breaks. Every item in the playbook below is something that this exercise surfaces.

The Playbook: Fundamentals at AI Scale and Speed

Each of these is written as what to do and how to actually get it done — because the advice-to-adoption gap is where most programs die.

The four moves: SEE → DECIDE → CONTAIN → RUN

1. SEE — know your environment, and keep watching

• The play: Map your environment (configuration graph) — what you run, what’s exposed to the internet, and how far one compromise can spread. Then keep watching: observability across your own environment, and threat intelligence for the outside view, so you know the moment a bug in vendor software starts being exploited in the wild.
• The advantage: The graph pays for itself immediately — dead code, unused open-source packages, and forgotten internet-facing servers you can simply remove — and it’s the asset list every other move depends on. Threat intel buys you early warning: you hear a vendor bug is being exploited when it’s announced, not when it hits you, so a compensating control can be in place before an attacker arrives.
• If you skip it: You defend blind — the breach starts at the asset you didn’t know you owned, and you learn about it from someone else.

2. DECIDE — spend your limited capacity where it matters

• The play: Prioritize by real exploitability, not raw severity — a “medium” on an internet-facing service one hop from customer data beats a “critical” on an isolated internal box (recently chains of Lows and Mediums were used in real compromises as well). Run two lanes: your own code you can fix, refactor, or rewrite; vendor code you can’t touch, so that lane is compensating controls and faster detection.
• The advantage: Your finite capacity goes to the few findings that could actually hurt you — and every flaw gets a response you can execute: a fix where you can, a shield where you can’t.
• If you skip it: Busy but not safer — capacity burned on findings no attacker could reach while the one exploitable path stays open, and months of exposure waiting on a vendor patch you could have mitigated in days.

3. CONTAIN — make sure one bug can’t become a breach

• The play: Segmentation splits the environment so a foothold in one place can’t reach the rest. Zero trust and least privilege make every person, service, and AI agent prove each request — and grant only the access it needs. When you can’t patch fast, mitigate: block the exploit path or take the exposed component offline. And when the same bug class keeps returning from the same code, fix the root cause — rewrite memory-unsafe components in a memory-safe language instead of patching the same flaw forever.
• The advantage: One exploited bug stays a contained incident instead of a company-wide breach — and containment keeps working even when patching can’t keep up.
• If you skip it: One bug becomes the whole environment — the first agentic ransomware ran its entire chain through doors these basics would have closed — and unfixed root causes bring the same bug class back every quarter.

4. RUN — make it continuous, and govern what runs it

• The play: Make scanning and fixing continuous and automatic, not quarterly — with the process defined before you accelerate: human-in-the-loop approval before fixes ship, a tested rollback path for when one goes wrong, and every AI agent wrapped in identity, least privilege, and human review from day one.
• The advantage: Machine-speed remediation that’s safe to run — and the whole playbook becomes a daily operating discipline instead of a one-time project.
• If you skip it: Quarterly scans mean months of exposure between runs; automation without approvals and rollback breaks production at machine speed; and an ungoverned agent becomes your newest insider threat.

None of these are new controls. What’s new is the bar. AI changed the speed and scale of the attacks, so the fundamentals have to run faster than they used to and cover everything with no exceptions.

The hard part isn’t technical

Every move above lands on someone else’s roadmap. Many are already on them, some for years. Segmentation changes how infrastructure operates; a continuous fix pipeline changes how developers ship; rewriting memory-unsafe components costs engineering quarters. Expect pushback — not because those teams don’t care about security, but because you’re asking to spend their time against their goals.

Three things buy the political capital: bring evidence, not mandates — the configuration graph and real exploitability data argue better than any policy memo; co-own the fix — show the risk and the trade-off, then let engineering own the how, because a rewrite they choose ships and a rewrite they’re ordered into stalls; and give leadership one number tying the work to risk reduced, so the effort defends itself at budget time.

Mandates breed quiet workarounds. Shared evidence and shared credit create movement.

The frontier agrees:

Anthropic, having surfaced the scale of the problem with Mythos, has focused on the fix: an automated pipeline that investigates, validates, and patches code vulnerabilities — delivered through Claude Code — with human review before anything ships.

Google frames it as AI threat defense: using AI across the whole vulnerability management lifecycle — finding, fixing, detecting, responding — wrapped in a framework and human review. The emphasis is on managing the end-to-end process, not any single tool.

OpenAI focuses on cyber-focused models — such as the GPT-5.6 series (including the Sol model) — which are designed to assist defenders with vulnerability identification, red teaming, and security validation, shifting the approach toward high-reasoning, specialized models capable of handling complex security tasks.

Different bets, same conclusion: none of them claims AI fixes vulnerability management for you — every one wraps the capability in process and human review.

The real reckoning

The vulnerability deluge is real, whatever you call it: AI made finding bugs cheap, and cheap discovery means more exploitation and more damage. But the reckoning isn’t that AI broke defense — it’s that the fundamentals matter more than they ever have. Use AI to find, to fix, and to move faster than you thought possible. But map your environment, limit how far a break-in can spread, fix the root causes, and keep a human on the decisions that matter.

Get the fundamentals right — that was always the strategy; now it’s the only one. Which of these is your program most under-invested in? That’s the conversation worth having…

P.S. This came out a bit too high-level, but this is admittedly for the high level audience…

Further reading and sources:

• “Breaking the Patch Sound Barrier” series
• Security incident disclosure — July 2026 (boring title award winner!)
• Google Secure AI Framework (SAIF)
• Google Threat Intelligence Group on the first AI-developed zero-day observed in the wild (2026).
• CoSAI Shared Responsibility for AI Security
• Anthropic — the post-Mythos code-patching pipeline via Claude Code
• Zero risk isn’t the job: a CISO’s guide to agentic AI
• First Take: OpenAI’s Hugging Face Hack — CISOs Must Focus on Fundamentals and Ignore the Hype (Gartner access required)

Beyond the Vulnerability Apocalypse: Scaling Your Basics and Vulnerability Management was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

So, you read my previous blog post about breaking the patch sound barrier, but it left you wanting more? Well, this is that “more.”

Here are three useful ideas to advance the conversation.

1. Defining the “Vulnerability Apocalypse”

People love to throw around terms like vulnerability apocalypse, but what does it actually mean? What is the crisp definition? Here:

Anton’s Vulnerability Apocalypse (VulnPocalypse) is …

… a rapid step increase in:

1. The number of software vulnerabilities (including zero-days i.e. vulnerabilities not known to defenders),

2. Speed of exploit development,

3. Volume of exploitation based on them,

4. Resulting incident damage.

With some help from the fine folks on Twitter and LinkedIn — and Gemini, naturally — the above is what I got.

Note that for a situation to truly qualify as “an apocalypse”, all four of these factors must be present simultaneously:

1. Massive Volume: A staggering influx of new vulnerabilities.
2. Rapid Exploit Development: Attackers weaponizing flaws nearly immediately.
3. Evident Exploitation: AI and automated tools scanning and exploiting at scale.
4. Severe Incident Damage: Widespread, material business impact resulting directly from these compromises.

The key? The fourth factor: incident damage. If you have a massive spike in vulnerabilities, but it doesn’t result in actual, widespread related damage, it isn’t an apocalypse — it’s just a high-volume vuln Tuesday.

How do we track that this is indeed coming? This is Part 3 of this saga, coming soon!

2. The Polarization of “Patch Faster”

Ever since advanced models capable of hunting down vulnerabilities emerged, the traditional advice of “just patch faster” has become incredibly polarizing.

Ultimately, my take aligns closely with a recent Cloudflare post: “Patching faster does not change the shape of the pipeline that produces the patch. If regression testing takes a day, you cannot get to a two-hour SLA without skipping it, and the bugs you ship when you skip regression testing tend to be worse than the bugs you were trying to patch.”

So, yes, do patch faster. And, no, patch faster won’t save you.

What will? This!

3. A Thought Experiment: The 15-Minute Magic Wand

Let me leave you with a useful thought experiment I recently used in a presentation.

Imagine you wake up tomorrow morning and, by pure force of magic, any vulnerability in your systems, applications, and operating systems can be patched within 15 minutes of patch release. The dream has come true!

Now for the fun part: Reverse engineer that reality.

What fundamental changes had to happen in your environment to make that 15-minute window physically possible?

If you actually run through this exercise, you will discover a goldmine of hidden opportunities. You’ll identify exactly where you can boost asset discovery, streamline software updates, automate testing, eliminate legacy roadblocks, and modernize your architecture. Fun!

Will it actually get your entire enterprise to a 15-minute patch cycle? No, probably not — and definitely not for every legacy application. But it will give you a concrete, actionable roadmap for modernizing your IT.

Let’s hope this was both fun and useful.

Related blog:

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

Breaking the Patch Sound Barrier Part 2: So Is The Apocalypse Coming and What Is It? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.