The End of Vulnerability Management as We Know It
The end of vulnerability management and what comes next.
Shaun Archer
6/29/20265 min read
Vulnerability Management Is Broken — and Patching It Won't Help
Let me be direct: most vulnerability management programmes are security theatre dressed up as process. Scan the environment, generate a list the size of a small novel, hand it to someone who wasn't in the meeting, watch it age in a ticket queue. Repeat quarterly. Maybe annually, if things are really going badly.
The people running these programmes know this. The engineers receiving the tickets know this. And yet the cycle continues, because it produces artefacts — reports, dashboards, closure rates — that look like a functioning security programme even when they're not.
Why Speed Isn't Even the Right Starting Point
The standard critique of VM is that it's too slow, and that's true, but it misses the more uncomfortable problem. Yes, mean time to remediate critical vulnerabilities averages around 60 days across most organisations. Yes, weaponised exploits for high-profile CVEs can appear within days of disclosure. The maths is terrible.
But the reason the maths is terrible isn't just the patching pipeline. It's that patching was never a viable strategy for closing exposure at scale. Emergency patches break applications. Patching windows exist because production systems don't restart cleanly. Vendor release cycles don't align with your threat landscape. And when you do patch, you're often introducing new risks — dependencies shift, configurations change, and a fix for one CVE occasionally opens a different door. Automated patching pipelines help at the margins; they don't change the fundamental dynamic.
If patching were instant, we'd still have the same problem. We'd just have it faster.
The Noise Is the Programme
The bigger issue is what scanners actually produce. They're very good at generating findings. They're much less good at telling you which of those findings matters in your environment — on your network, with your exposed services, given who's actually coming after organisations like yours.
Most scanner output is theoretical. A vulnerability in a database with no network exposure, sitting behind authentication, requiring local admin access to trigger, is not the same risk as the same CVE in an internet-facing API. Traditional VM treats them identically. That's how you end up with a list of 4,000 findings, most of which are unexploitable given your actual environment, and an engineering team that has quietly stopped believing the severity ratings mean anything.
This is sometimes called a false positive problem. It's really a context problem. Scanners historically had no understanding of effective reach — actual network topology, real attack paths, what an attacker would need to chain together to get somewhere useful. Without that context, everything looks equally urgent, which means in practice nothing gets treated as urgent.
CVSS Was Built for Nobody in Particular
CVSS was designed to give a standardised, vendor-neutral score — useful for software vendors describing their own flaws, much less useful for security teams deciding what to fix this sprint. Scores are computed without any knowledge of your environment, your architecture, or the threat actors that are actually interested in organisations like yours.
A 9.8 on software you don't run is irrelevant. A 6.5 on a widely deployed authentication service with active exploitation happening right now in your industry is genuinely urgent. CVSS gives you the same answer for both.
This is the same failure mode as compliance benchmarks. CIS controls are useful. They're not calibrated to your threat model. Treating CVSS like a to-do list — close the 9s, deprioritise the 5s — produces the appearance of a functioning programme. Whether it reduces actual risk is a separate question that most teams aren't measuring.
Your Environment Doesn't Sit Still
There's a compounding factor that wasn't true ten years ago: modern infrastructure changes constantly. IaC pipelines push hundreds of changes a day. Microservices come up and down. Cloud configurations drift. Service accounts, API keys, OAuth tokens, CI/CD credentials — non-human identities — are performing automated workflows that modify your environment continuously, often without a human ever reviewing what changed.
Agentic AI workflows make this harder still. AI agents can provision resources, modify configurations, and create new integrations with no change ticket attached. The exposure map from this morning may already be wrong.
A programme built around weekly scans — or monthly, as many are in practice — can't keep up with this. It's not a resourcing problem. It's a structural mismatch between how the programme was designed and how the environment actually behaves.
Catching It Earlier
The most practical near-term lever is stopping vulnerabilities from being introduced rather than scrambling to remediate them after the fact. IaC scanning, SAST tooling, SCA for open-source dependencies, secret detection in CI/CD pipelines — none of this is new, but tooling maturity has reached the point where it's genuinely useful rather than aspirational.
What's improved is accountability. The better implementations tell you who introduced the vulnerable code, in which commit, so the feedback reaches the developer before anything merges — not three weeks later as a ticket from a team they've never met. That changes the economics significantly. A finding in a pull request is cheap to fix. The same finding in production is expensive, slow, and requires a patching window.
It's not a complete answer — pre-production scanning misses runtime misconfigurations and issues introduced through third-party updates. But it shifts the distribution of where findings come from, and that matters.
EPSS Is Worth Your Attention
EPSS — the Exploit Prediction Scoring System — doesn't get enough airtime given how useful it is. Where CVSS scores theoretical severity, EPSS estimates the probability that a given vulnerability will be exploited in the wild over the next 30 days, drawing on threat intelligence, proof-of-concept availability, and exploitation telemetry. It updates continuously rather than being fixed at publication.
Used alongside CVSS, it gives you something closer to a real prioritisation signal. A critical CVSS score with a negligible EPSS probability is real risk, but probably not this week's fire. A medium CVSS with a spiking EPSS score means something is being actively weaponised — push it up the queue regardless of the abstract rating.
EPSS isn't perfect. It lags on brand-new CVEs and can't predict novel exploitation. But it's a meaningful improvement over treating a published score as the final word on priority.
Exposure Management Is the Right Frame
Gartner's Continuous Threat Exposure Management (CTEM) framework has attracted a lot of attention, and while Gartner categories should always be taken with a degree of scepticism, this one is pointing at something real.
Traditional VM asks: what vulnerabilities exist in my environment? CTEM asks: what can an attacker realistically exploit to cause harm? Those are different questions with different answers. CTEM incorporates attack path analysis, asset criticality, identity risk, and live threat intelligence rather than treating the CVE feed as the whole input. It's continuous rather than periodic. VM doesn't disappear; it becomes one input into a broader process rather than the programme itself.
For a lot of practitioners, this reframe is already how they think. The category name is new. The underlying logic — prioritise based on realistic exploitability and business impact, not abstract scores — has been the right instinct for years. CTEM is just what it looks like when that instinct gets operationalised.
Where This Leaves Us
Traditional vulnerability management made sense when infrastructure was stable, changes were infrequent, and attacker timelines were measured in weeks. Most enterprise environments no longer look like that, and the gap between how the programme operates and how the threat landscape actually behaves has become difficult to justify.
The organisations doing this well have generally stopped treating VM as the programme and started treating exposure reduction as the goal — which sounds like semantics until you see how differently the two frame daily decisions. What can an attacker actually reach? What's being actively exploited right now? What's the blast radius if this gets compromised? Who introduced this exposure and how do you stop it coming back?
Those are harder questions than whether the critical ticket queue is empty. They're also the ones worth asking.