A couple of months back, a pair of security researchers pointed AI agent swarms at the Windows kernel drivers shipped by AMD, Intel, NVIDIA, Dell, Lenovo and IBM. In 30 days, for $600 of compute, they found over 100 exploitable vulnerabilities. Four dollars a bug.

More recently, the UK AI Security Institute published its evaluation of Anthropic's Claude Mythos Preview. It was the first model to complete a 32-step simulated corporate network attack end-to-end, a piece of work AISI reckons would normally take a human expert about 20 hours.

Both of those numbers would have been unthinkable a couple of years ago but I don't think either of them is an outlier any more. Together, they make a strong case for rethinking the conventional approaches to vulnerability management.

In a previous post I mentioned the OODA loop (Observe, Orient, Decide, Act) in the context of threat-led VM. The theory, borrowed from military strategy, is that the side that gets round its loop fastest has the advantage. It maps fairly neatly onto vulnerability management: find, prioritise, approve, remediate. The problem is that when you actually measure what's going on at each of those four stages, the defender's loop is getting slower at the same time that the attacker's loop is collapsing.

A quick word on the military framing before I go on. I know it doesn't sit comfortably with everyone in cyber, and I've got no interest in pretending we're at war with teenagers. I've kept OODA because it forces a question that a lot of vulnerability management programmes don't really ask: at which stage of this cycle are we actually losing? If the framing doesn't work for you, take it as a useful lens rather than anything more.

The defender's loop, stage by stage

Before getting to what to do about it, it's worth walking through what's actually happening at each stage. The numbers below are drawn from threat reporting by CrowdStrike, Rapid7, Google Threat Intelligence Group, Sonatype, VulnCheck, the Cyentia Institute, and the Zero Day Clock project.

Observe

This is the stage where you try to work out what you're exposed to. Assets, SBOMs, attack surface, the CVEs that might affect you. All of that is growing faster than most organisations can keep up with. CVE volume hit roughly 48,000 in 2025, up from 25,000 in 2022. Sonatype reckons 704,102 malicious packages have been spotted in the open-source ecosystem since they started proactively hunting for them in 2019. Earlier this year the Axios npm package, with over 100 million weekly downloads, was compromised via stolen credentials; most organisations running it probably didn't know it was in their stack.

The real problem at Observe isn't that we can't see things. It's that the boundary of what we need to see keeps moving faster than we can map it. SaaS, CI/CD, identity planes, edge devices, transitive dependencies; every one of those has extended the surface in the last five years.

Orient

Knowing a CVE exists doesn't tell you whether it matters. Does it affect you? Is it reachable in your architecture? What's the blast radius if someone gets to it? These are context questions, and the context is usually in bits across several teams and tools.

Most of the vulnerability management programmes I've worked with still prioritise on CVSS first, with exploitation intelligence as an afterthought. That produces urgency at scale, which is not the same as prioritisation. FIRST's EPSS data (analysed by the Cyentia Institute) puts the share of published CVEs ever exploited in the wild at around 6%. VulnCheck's 2026 Exploit Intelligence Report is sharper on last year specifically: of the roughly 48,000 CVEs disclosed in 2025, only about 1% have been observed exploited in the wild so far, and fewer still have confirmed links to named ransomware or nation-state actors.

If your triage queue treats a third of incoming findings as urgent, you haven't prioritised anything. You've just turned the volume up. The tooling to do it better exists (EPSS, CISA's Known Exploited Vulnerabilities catalogue, Continuous Threat Exposure Management platforms like Wiz, Nucleus Security and Vulcan Cyber), but the underlying problem is data. Without proper asset inventories, dependency graphs and a reasonable picture of your own architecture, no amount of clever tooling will give you the context you need.

Decide

This is where the numbers start to get uncomfortable. In 2018, the median time from CVE disclosure to first observed exploit was 771 days. By 2023 it was 6 days. By 2024 it was 4 hours. In 2025, the majority of exploited vulnerabilities were being weaponised before public disclosure, according to the Zero Day Clock.

Over the same period, the defender's Decide stage hasn't really moved. Change advisory boards, approval workflows, maintenance windows; most enterprises still operate at a tempo measured in weeks. Most of us have policies saying critical vulnerabilities should be patched within days, but in practice that rarely happens. Partly because of the technical constraints I'll come to in a moment, and partly because the business has other priorities. Teams can't realistically drop everything every time a Critical lands. The policy says one thing; the culture does another.

And the deeper issue is that Decide gets more conservative the slower Observe and Orient are. If you're not sure what's important, the safest thing to do is always to wait a bit longer. That's fine when exploitation takes 771 days. It's catastrophic when it takes 4 hours.

Act

Patching takes as long as it takes, and the reasons are well known to anyone who has ever tried to run a vulnerability management programme. Change windows. Regression testing. Vendor release cycles. Third-party code that isn't yours to fix. One vendor benchmark (worth a caveat, because it's a vendor blog) suggests defenders need around 55 days on average to patch 50% of critical CVEs. Even if you halve that, you're still in weeks-scale territory against hours-scale exploitation.

The attacker side of that comparison is no less uncomfortable. CrowdStrike's 2025 Global Threat Report puts average eCrime breakout time at 29 minutes, with the fastest recorded at 27 seconds. Rapid7's 2026 Global Threat Landscape report found the median time from vulnerability publication to CISA KEV inclusion fell to 5 days, down from 8.5. And Google Threat Intelligence Group notes that 48% of zero-days in 2025 targeted enterprise software and edge devices, which is exactly where the defender's Act stage is slowest.

And then AI showed up

Everything above was roughly where things stood a year ago. AI-capable offence has tilted the curve further. Daniel Kang's research demonstrated AI-generated exploit pipelines running at around $8.80 per exploit with an 87% success rate. I've already mentioned the $4-a-bug number from the Windows driver work, and the AISI evaluation of Mythos Preview. Anthropic's Project Glasswing announcement in April is the one that shook me most: a frontier model running against live codebases at some of the biggest technology companies in the world, finding vulnerabilities that had sat undetected in open-source projects for decades.

A couple of things are worth saying about all of this. Mythos Preview isn't uniquely capable so much as visibly ahead of a curve; cyber capabilities across frontier models are improving, and the gap to the next tier is smaller than the headlines suggest. The AISI evaluation is a useful data point, not a single-vendor story. It's also worth asking what it means that this kind of capability is currently concentrated in a handful of frontier labs. The organisations that can afford access benefit; the wider industry mostly doesn't yet, and that unevenness is itself a risk worth naming.

AISI has also been refreshingly honest about the limits of their own work. Their test ranges lack active defenders, don't have EDR running, and impose no penalty on the model for triggering alerts. The headline numbers are close to a best case for the attacker, which tells you where defenders still have room to move; architecture and active monitoring still change the picture, and I'll come back to that.

The decoupled battlespace

So what do we do about it? For me, the answer is to stop trying to design one perfect patch loop and start designing the environment the patch loop operates in. To coin a phrase, I'm going to call this the decoupled battlespace.

A decoupled battlespace is an architecture where containment and compensating controls can operate at minutes-to-hours tempo, even when patching and change management operate at days-to-weeks. The goal is to let different parts of the organisation run at different tempos without the slowest loop setting the outcome for everyone else.

Before describing what this looks like in practice, I want to deal with an assumption built into most vulnerability management conversations. When we talk about "the defender's OODA loop" versus "the attacker's OODA loop", we imply that each side has one loop. The attacker might. The enterprise doesn't.

An enterprise is made up of many teams, each running their own decision cycles, and most of those aren't security cycles. App teams are iterating on features. Platform teams are managing capacity. Change management is balancing risk against availability. Each has its own tempo and its own priorities, and the security loop is rarely the one that wins when there's a conflict. "Patch faster" fails as a universal instruction precisely because it assumes you can accelerate a single unified loop. In practice, you're trying to coordinate dozens of them across teams with genuinely competing objectives.

The security team needs to be able to run its own loop independently, at its own tempo, while other teams carry on at whatever pace their work requires.

In a traditional VM model, everything sits on a single timeline. A CVE is published, goes into a queue, gets triaged, assigned, tested, approved, deployed. Every stage is sequential. The chain is only as fast as its slowest link, which is usually change management or a third-party dependency. In a decoupled model, you accept that reality and design around it. You create architectural layers where security can act independently and immediately, buying time for the slower but necessary remediation process to complete properly. You don't eliminate the patch loop; you make it so the patch loop doesn't have to be the only thing standing between you and a bad outcome.

Simon Goldsmith makes a related point using Simon Wardley's evolution lens: attack capability has become a commodity (subscription-priced, low-skill, standardised) while a lot of defensive practice is still artisanal. The mismatch isn't primarily about working harder inside the same model; it's about recognising what kind of activity we're running and building defences that match the threat's maturity. The decoupled battlespace is, in that framing, what commodity-grade defence looks like for the containment problem.

Here are five plays, in the order I'd prioritise them.

1. Centralised transit

The most impactful single decision in a decoupled battlespace is creating a central control point for traffic, inbound and outbound.

If all inbound traffic terminates through an API gateway or WAF tier with centrally managed policy, and all outbound access routes through a central proxy or DNS enforcement layer, then security can deploy mitigations (virtual patches, block rules, traffic shaping) without requiring any change to the application itself. The outcome isn't "we patched instantly"; it's "we reduced exploitability quickly, while the app team tests and deploys the real fix on a normal change cadence". In that model, security operates in minutes while app teams carry on at sprint cadence, and nobody's tempo has to win.

I'd be dishonest if I painted this as simple. In most enterprises I've seen, the reality is messy. Many organisations have 15 years of accumulated technical debt; applications talk directly to each other; traffic flows are undocumented; there's no natural single ingress or egress point because the network grew organically. App teams don't want a central gateway they don't control. Platform teams don't want to own a chokepoint that could cause an outage. Central transit also introduces a real single point of failure if the resilience engineering is wrong; this isn't a proxy you drop into the path and call done.

In my experience, the pragmatic starting point is new workloads rather than brownfield. Mandate that any new service deploys behind the central gateway from day one. For existing workloads, prioritise internet-facing and high-risk services first. Build the muscle, prove the value, then expand. The metric worth tracking is this: what proportion of our internet-facing attack surface can security mitigate independently, without an application change, inside an hour? If the honest answer is close to zero, that's where you start.

2. Default-deny egress and segmentation

Most supply-chain attacks follow a recognisable shape. Malicious code gets in via a compromised dependency, a poisoned update or a stolen credential, and then it needs to do something: phone home, pull down a second stage, move sideways, exfiltrate data. The attacker is relying on your environment to let all of that happen. The Axios compromise worked like this. So did SolarWinds.

The response is default-deny egress and segmentation. CI/CD runners and build agents shouldn't have direct internet access; they should pull dependencies through an approved artefact proxy that security controls. New outbound destinations need explicit allow rules. High-risk zones (build environments, identity infrastructure, management planes) should be segmented with default-deny east-west rules, so that a compromise in one zone doesn't automatically hand over the next.

The important distinction here is that this isn't primarily about preventing compromise. It will happen. It's about making sure that when it does, the blast radius is contained regardless of how quickly you can patch. The attacker's speed advantage doesn't automatically translate into impact, because you've designed the environment to absorb the hit.

What makes this hard? Developers find it painful, at least initially. "I can't pip install from the internet on the build server" is a real friction point. You need to invest in the artefact proxy, make it fast and reliable, and make the developer experience good; if the secure path is slower and more painful than the insecure path, people will find workarounds. Shadow IT is the structural version of the same problem: if teams can spin up their own cloud resources outside your control, your segmentation model has holes you don't know about, which takes you straight back to the Observe problem. Cloud governance and asset management aren't separate workstreams from vulnerability management; they're prerequisites. And managing egress rules across hundreds of microservices is genuinely non-trivial; it needs tooling, automation and clear ownership. This isn't a project you close; it's an operating model you maintain.

Getting default-deny egress right across an enterprise is a multi-year journey. The earlier you start, the better positioned you are when the next supply-chain incident lands.

3. Containment zones (and what OT got right)

OT (Operational Technology) environments are useful to think about because they've had to face this problem squarely for years, without the option of patching their way out of it. Systems run 24/7, they control physical processes, and a bad update doesn't cause a degraded user experience; it causes a production line to stop (or worse). So OT security has evolved around the assumption that the patch loop cannot be the primary control. What that looks like in practice is zones and conduits, strict gateways between trust levels, mediated access to sensitive systems, behavioural monitoring, and defence in depth as an operational necessity rather than a marketing phrase.

My argument is that large parts of the enterprise IT estate have quietly become more like OT than we'd care to admit. Third-party SaaS you can't patch because you don't control the timeline. Edge devices and IoT with the same constraint. Legacy applications that "just work" and that nobody dares touch. The 48% of zero-days targeting enterprise software and edge devices that GTIG flagged? Those are landing on the bits of the environment that already behave like OT, whether we've labelled them that way or not.

And when you come back to AISI's caveat about the Mythos Preview test range (no active defenders, no EDR, no penalty for triggering alerts), that's exactly the gap a containment model is designed to open up. Against a well-segmented, actively-monitored environment, an autonomous attacker still has to deal with a defender that can see what's happening and respond. That's an architectural advantage available to any organisation willing to treat containment as a design goal rather than something you get round to if there's budget left.

For each major system or zone in your environment, the question worth asking is: if a zero-day drops tomorrow and you can't patch for 30 days, what happens? For many organisations, the honest answer isn't "we're fully exposed". It's worse: "we don't actually know". NIS2 and DORA are starting to force this question for organisations in scope; for those outside those regimes, it remains voluntary, and voluntary exercises tend to lose out to competing business priorities. That's the Observe and Orient problem all over again.

4. Exploitability-driven prioritisation

Orient is where most VM programmes are weakest, and also where the biggest wins are closest to hand. The shift you're trying to make is from "what's the severity?" to "what's actually exploitable in our environment?".

Start with exploitation intelligence. CISA KEV, EPSS scores and in-the-wild signals should be the first filter, not CVSS. If a vulnerability has a 0.1% EPSS probability and no observed exploitation, it probably isn't your Tuesday morning emergency, even if it's rated Critical. Layer architectural context on top: is the vulnerable component internet-facing? Is it behind your WAF tier? Is it in a segmented zone? Does your egress policy already block the exploitation path? This is where the decoupled battlespace pays dividends for Orient directly; your architectural controls change the exploitability calculus, so investing in sections 1 to 3 also makes your prioritisation better.

Then automate the enrichment. Orient is slow not because people don't know what questions to ask, but because answering them means manual work across five different tools and three different teams. CTEM platforms like Wiz (for cloud context), Nucleus Security and Vulcan Cyber (for vulnerability orchestration), and ServiceNow VR (for workflow integration) are increasingly able to map a CVE to your asset inventory, architecture topology and existing control coverage automatically. None of them are perfect, and most require significant investment in underlying data quality; you can't automate enrichment against an asset inventory you don't have. But the direction is clear: Orient should be a data problem, not a manual research exercise.

For every vulnerability entering triage, I'd try to answer three questions before assigning priority:

  1. Is it being exploited in the wild? (KEV, EPSS, threat intel)
  2. Is it reachable and exploitable in our specific environment? (Architecture, asset exposure, control coverage)
  3. If it were exploited, what's the blast radius given our current segmentation and containment?

If the answer to the first is "yes" and the answer to the third is "catastrophic", it's a hair-on-fire priority. If the answer to the first is "no" and the answer to the third is "contained", it can reasonably wait for the next maintenance window. This is not rocket science, but it does need the architectural and data foundations to answer the questions quickly; and those are the same foundations the rest of the decoupled battlespace requires.

5. Where AI actually helps

The biggest time sink in Orient is the manual work of understanding whether a CVE is actually exploitable in your environment. A model that can reason over code paths, dependency graphs and architecture topology can compress that from hours or days to minutes. When a critical vulnerability drops and you need a WAF rule or virtual patch quickly, AI can generate and test candidate mitigations as deployable artefacts, which feeds directly into the centralised transit model from section 1. And for the parts of the environment running on an OT-style containment approach, where patching cycles are long or impossible, AI-driven behavioural analysis provides the early warning layer that compensates.

What AI doesn't fix is organisational dysfunction. It doesn't fix missing asset inventories. It doesn't fix the political problem of getting app teams to route through a central gateway. And it doesn't replace human accountability for risk decisions. As I wrote in my AI orchestration piece, the key is building governance in from the start, not bolting it on after the fact.

Three questions for Monday morning

If you want to know where your organisation stands, here are three questions worth taking to your next leadership meeting.

What proportion of our internet-facing attack surface can security mitigate independently, inside an hour, without an application change? If the answer is low, Decide has no slack and every incident turns into a fire drill.

If a critical supply-chain component is compromised tomorrow, what's the maximum blast radius? If the answer is "we don't know" or "everything", containment hasn't been invested in. Patch speed is all that stands between a compromise and a serious incident; and given the numbers earlier in this piece, that's not where you want to be.

How much of our vulnerability triage is driven by exploitability intelligence rather than CVSS? If the answer is "mostly CVSS", Orient is generating false urgency at scale and your teams are probably exhausted as a result.

Where does that leave us?

The strategic question for a security leader isn't how to make their vulnerability management programme run faster. It's a question about which stage of the loop is weakest, and where a bit of investment might actually shift the odds.

In most of the organisations I've worked with, the honest answer is uncomfortable. Budgets tend to cluster around Act and the latter half of Orient: scanners, detection tools, triage workflows, response capability. Relatively little goes into Observe (asset inventory, SBOM quality, architecture mapping) or prevention at origin. Decide tends to be under-invested because it's an organisational and cultural problem rather than something a vendor can sell you.

None of these strategies wins on its own:

Together, they reshape the environment the loop runs in; which, given how much the attacker's loop has compressed, is probably the only move that actually changes the odds.

One last thing worth saying: the decoupled battlespace sits alongside prevention at origin, not instead of it. Goldsmith argues persuasively that the highest-leverage long-term investment is stopping defects entering the deployable artefact in the first place (context-aware IDEs, policy-as-code, build-time invariants). I agree with the direction. But no realistic organisation ships only verifiably secure code tomorrow, and none of us fully control the third-party code we depend on. The decoupled battlespace is the architecture that keeps you solvent on the journey to that goal.

The organisations that come through the next decade in reasonable shape won't be the ones that patched fastest. It will be the ones that realised tempo alone wasn't a game they could win, and shaped their environments accordingly.