The CVE Treadmill: Why You Can’t Patch Your Way to Security
In cybersecurity, few practices feel as comforting, or as misleading, as patching. The industry still treats Patch Tuesday like a ritual, celebrates hitting patch SLAs, and reports the percentage of systems updated to boards as evidence of control. Yet defenders know the reality: Patching has become little more than security theater. Dashboards glow green while attackers run circles around us.
That treadmill keeps accelerating. In 2024 alone, more than 40,000 CVEs were cataloged, a 38% increase over the year before. But the real problem isn’t just volume. It’s timing. Some of the most damaging breaches in recent memory, like MOVEit and WinRAR, were exploited before their CVEs were even published. By the time defenders reach for the patch button, attackers are already inside.
Why Patching Alone Fails
The first problem is scale. With tens of thousands of new vulnerabilities each year, even well-resourced security teams cannot keep up. Prioritization frameworks like CVSS or EPSS promise to help, but in practice, they reduce complex exploitability to a single score divorced from real-world context.
To cope with this volume, organizations increasingly turn to external threat intelligence to prioritize backlogs. Models built on what’s being exploited elsewhere, aggregated across industries and geographies, offer a step forward from raw CVSS scores. But this approach has a fundamental limitation: external intel tells you what’s dangerous in the aggregate, not what’s exploitable in your specific environment. The challenge security teams often face in understanding their own IT environment has them looking outward more than inward for prioritization context.
A vulnerability actively exploited against healthcare organizations may be irrelevant to your architecture if the affected component isn’t running. Meanwhile, a “medium” severity CVE in software that runs with SYSTEM privileges on an internet-facing server could be your most urgent exposure. Prioritization vendors have built real businesses helping security teams sort their CVE backlogs. But sorting isn’t the same as understanding. Until you know what’s actually exploitable in your environment, with your configurations, at this moment, you’re still making educated guesses.
Timing compounds the challenge. Exploit kits often circulate in underground forums long before an advisory is issued. This pre-CVE window has become a prime hunting ground for attackers, leaving defenders with nothing to patch until it’s too late.
Even when patches exist, the gap between theory and practice remains wide. Downtime concerns, change freezes, and operational constraints mean patches cannot always be applied immediately. And many applications will never receive a patch at all. Legacy software long out of support, open-source projects abandoned by their maintainers, internal tools built outside formal processes: all continue to run inside enterprise environments, invisible to vendor advisories.
The Treadmill in Practice
For most large organizations, the cycle is painfully familiar. A new CVE drops. The security team scrambles to validate it, checks the CVSS score, scans the KEV list, and cross-references EPSS. A patch sprint follows, but business units push back on downtime, IT slows the rollout, and before the fix is applied, another CVE has arrived. The loop restarts before the last lap is finished.
The cost isn’t just fatigue. It’s misdirection. Security teams don’t patch anything directly. They generate demand on other teams: IT ops, system administrators, and application owners. They run the scanner, produce the report, and push prioritization over the wall to teams they don’t control. When those teams are overwhelmed and pushing back, security loses credibility. Patch counts rise, compliance reports look pristine, yet the vulnerabilities that matter most remain unmeasured and unmitigated.
When I was a CISO, I recall walking into meetings with a beautiful dashboard showing patch coverage as green. Everything was “under control.” And yet the headlines were full of organizations getting breached through vendor products that didn’t even have a CVE yet. That was the gut-punch moment. The reporting made us look secure, but I knew our actual exposure was sitting in that gap.
That’s when I started pulling our Red Team into the process. Not to run pentests, but to manually validate which of those thousands of “critical” CVEs were actually exploitable in our environment. It worked, but it didn’t scale. We were sampling a fraction of our attack surface and still drowning. That experience is why I eventually built Spektion: to do what my Red Team did, continuously and comprehensively.
The Inflection Point
We’ve been here before. In the early 2000s, signature-based antivirus reached its breaking point. Malware authors iterated faster than vendors could write signatures. Polymorphic threats changed their appearance on every execution. The industry responded by adding behavioral detection, watching for when potentially malicious behavior occurs at runtime rather than matching it against a catalog of known bad.
Vulnerability management is at the same inflection point. Static CVE-chasing (scan, match against a list, prioritize by score and intel) is the new signature matching. It mostly worked when the list was manageable, the scores were meaningful, and the intel was the best context available. It’s failing now for the same reason signatures failed then: the adversary moves faster than the catalog.
The shift that saved endpoint protection is the shift that will save vulnerability management: from static lists to runtime visibility.
From Static to Dynamic
Runtime visibility means watching how applications behave, specifically within your environment, not just cataloging what they are. When software reads LSASS memory, accesses SSH keys, opens network-exposed Named Pipes, marks memory pages as both writable and executable, or creates injectable conditions, those are classic precursors to exploitation. None requires a CVE to be dangerous.
Through this behavioral lens, security teams gain something patching can never provide: real-world context. A so-called medium vulnerability in a privileged application may be far riskier than a critical CVE in a utility with no meaningful exposure. Teams can identify and remove unused or shadow software, shrinking both operational noise and attack surface in ways patches never could.
The Acceleration Problem
And the challenge is about to get harder. AI has fundamentally lowered the barrier to software creation, not just for vendors shipping commercial products, but for internal teams and citizen developers building their own tools.
When a developer uses an AI coding assistant to generate a data-processing script and deploys it straight to production, the traditional vulnerability management model breaks down completely. There’s no vendor to issue an advisory. No entry in the CVE database. No patch cycle to follow. The script either behaves safely or it doesn’t, and the only way to know is to observe it at runtime.
Scan, prioritize, patch. That methodology was designed for a world where software came from known sources, on predictable timelines, with documented vulnerabilities. That world is fragmenting. Software creation is becoming atomized, distributed across vendors, internal teams, contractors, and AI assistants. Organizations that want to manage risk in this environment will need to understand the actual behavior of software, not just its known vulnerabilities. They’ll need to mitigate threats whether or not a CVE exists, and whether or not a patch is available.
Escaping the Treadmill
Running faster isn’t the answer. Adding more analysts, buying bigger scanners, or pressuring IT to patch faster doesn’t change the physics of the CVE cycle.
The way out is to shift both left and right of patching. Left, by spotting exploitability before disclosure through runtime intelligence. Right, by validating whether software in your environment behaves in ways that magnify blast radius.
Patching will always matter, but it will never be enough. The CVE treadmill has to stop. The question every security leader should be asking isn’t “how fast can we patch?” It’s “which of the thousands of critical CVEs in our backlog are actually exploitable in our environment?”
If you can’t answer that question, you’re still running. Runtime visibility is how you finally step off.
