The Treadmill You Can't Step Off
Your vulnerability scanner just finished. You've got 47,000 findings. Patch Tuesday drops in six days. Your CISO wants a compliance dashboard that shows green. And somewhere in that pile of CVEs, there's probably something that will actually get you breached — but good luck finding it before your SLA clock runs out.
This is the vulnerability management treadmill. You're running hard, you're sweating through your shirt, and you're going absolutely nowhere. The queue never empties. The risk doesn't meaningfully shrink. And yet every quarter, someone presents a slide showing "patch compliance at 94%" like that's a security outcome and not just a number.
Let's talk about why the whole model is broken and what practitioners who've actually thought about this are doing differently.
CVSS Is a Lie You've Been Told to Trust
The Common Vulnerability Scoring System was never designed to be a prioritization tool. It was designed to describe the characteristics of a vulnerability — how it's attacked, what privileges it needs, what the theoretical impact is. The people who built it will tell you this. FIRST has said it explicitly in their documentation. And yet somehow, every vulnerability management program in existence has "patch all Criticals in 7 days" baked into their policy, with Critical defined as CVSS 9.0+.
The result? You're spending your team's finite patching capacity on vulnerabilities that have zero exploitation activity in the wild, because some researcher gave them a 9.8 for theoretical remote code execution under conditions that don't exist in your environment. Meanwhile, something with a CVSS of 6.5 that CISA added to the Known Exploited Vulnerabilities catalog three weeks ago is sitting in your backlog marked "Medium — patch within 30 days."
I watched a team spend two weeks in emergency change windows pushing patches for CVE-2021-44228 — Log4Shell, fair enough, that one was real — while simultaneously ignoring CVE-2021-40444 (MSHTML remote code execution) that was actively being used in targeted attacks. Both were in the environment. One had more noise around it. You can guess which one got patched first.
The EPSS model — Exploit Prediction Scoring System, maintained by FIRST — actually tries to solve this. It uses machine learning across real-world exploitation data to give you a probability score: what's the likelihood this CVE gets exploited in the wild in the next 30 days? A CVSS 9.8 with an EPSS score of 0.003 is very different from a CVSS 6.5 with an EPSS score of 0.847. That second one is actively being weaponized. The first one is theoretical. Your SLA-based policy treats them identically, or worse, inverts the priority.
Layer CISA's KEV catalog on top of that. If CISA has confirmed active exploitation and added it to KEV, that's a signal you can't dismiss — federal agencies are required to patch KEV entries within defined windows, and the catalog is maintained conservatively. It's not perfect and it skews toward government-relevant threat actors, but cross-referencing your scan results against KEV takes about five minutes and immediately separates "someone found a bug" from "adversaries are using this right now."
The prioritization stack that actually makes sense: KEV first, high EPSS second, CVSS as a tiebreaker or for net-new CVEs with no exploitation data yet. Not the other way around.
Scanner Sprawl and the Illusion of Visibility
Here's a scenario that's more common than anyone wants to admit. You've got Tenable Nessus credentialed scanning your on-prem Windows estate. Qualys agent-based scanning on your Linux servers because someone decided agents were better for dynamic cloud instances. Rapid7 InsightVM doing authenticated scans on your network devices. A separate tool for container image scanning in your CI/CD pipeline. And your cloud provider's native security tooling — let's say AWS Inspector or Azure Defender — running on top of everything in the cloud.
Five tools. Zero unified view. And every single one of them disagrees on what's installed where.
The deduplication problem alone will age you. Tenable finds 340 vulnerabilities on a given server. Qualys finds 290. The overlap is maybe 210. Some of those differences are scan timing. Some are credential coverage — the agent sees things an authenticated network scan misses because it's looking at the actual running process table, not inferring package versions from registry keys. Some are just vendor-specific detection logic differences. You end up with analysts triaging the same vulnerability three times across three tools, updating tickets in two different systems, and still not knowing if the asset is actually patched because the tools reconcile on different schedules.
The asset inventory problem underneath this is usually worse than the scanning problem. Vulnerability management is fundamentally an asset management problem. If you don't know what you have, you can't assess it. If your CMDB is six months stale — and most CMDBs are — your scan coverage reports are fiction. You're showing "98% of assets scanned" because 98% of what's in your CMDB got scanned, but your CMDB doesn't have the shadow IT Linux box your dev team spun up in AWS three months ago, and it doesn't have the contractor laptop that's been on your corporate network for six weeks.
I've seen organizations drop significant money on Tenable.io or Qualys VMDR enterprise licenses specifically to get unified dashboards, and then spend twelve months trying to reconcile the data into something accurate enough to act on. The tooling isn't the constraint. The data quality is the constraint. No scanner vendor will tell you that in a sales call.
The SLA Trap
SLA-based patching feels like accountability. Critical: 7 days. High: 30 days. Medium: 90 days. Low: best effort or never. It goes in your policy document, it satisfies auditors, it gives management something to measure. It also has almost no relationship to actual risk reduction.
Think about what that 7-day SLA for Criticals actually means operationally. Your scanner runs, finds a new Critical. Your ticketing system auto-generates a ticket. That ticket lands in some team's queue. They need to identify the affected asset owners, test the patch in a non-prod environment, schedule a change window, deploy, verify, close the ticket. In seven days. For every Critical CVE in the environment. While also doing their actual jobs.
What happens in practice is one of a few things. The team patches the things that are easy to patch — the things where the vendor has a clean update mechanism and there's no meaningful risk of a broken deployment — and marks the tickets closed. The hard ones, the ones with complex dependencies or where the patch has known issues or where the asset is so critical that any unplanned downtime is a major incident, those get exceptions. Lots of exceptions. Your compliance dashboard shows 94% because the 6% in exception status is invisible to the metric.
Or the team starts rubber-stamping patches without testing. "We have to close this in 7 days, there's no time to test." Windows KB rollbacks are not a hypothetical. The January 2022 Windows Server update (KB5009557) famously broke domain controllers with specific configurations. The August 2024 CrowdStrike incident wasn't a vulnerability patch, but it illustrated exactly what happens when you push changes to critical systems without adequate validation. Rushed patching under SLA pressure creates a different category of availability risk that your vulnerability management policy doesn't account for.
Risk-based patching actually asks different questions. What's the likelihood this vulnerability gets exploited against this specific asset? What's the business impact if that asset is compromised? What compensating controls exist that reduce the effective risk even if the patch isn't applied immediately? Can we accept elevated risk on this asset for 30 days while we properly test the patch, given that it's behind a WAF, network-segmented, with EDR coverage and enhanced logging?
That last question is where compensating controls become a legitimate tool rather than an excuse. A vulnerability that's theoretically exploitable remotely means something very different on an internet-facing system with no WAF coverage versus a backend database server that's only reachable from two application servers on a private VLAN with network-level monitoring. CVSS doesn't capture that. Your SLA policy doesn't capture that. An analyst who's thought about it for five minutes can capture that.
SSVC: The Framework Nobody Talks About Enough
The Stakeholder-Specific Vulnerability Categorization framework, developed out of Carnegie Mellon's CERT/CC and now maintained collaboratively with CISA, is the most practically useful thing to happen to vulnerability prioritization in years and it's criminally underused.
The core insight of SSVC is that a vulnerability's priority should be a decision — specifically, what should the affected organization do, and when — not a score. You work through a decision tree that considers exploitation status (is it being actively exploited?), automatable exploitation (can it be scripted at scale?), technical impact (does exploitation give full system control or something lesser?), and mission/business impact specific to your organization's use of the affected asset. The output isn't a number from 1 to 10. It's one of four actions: track, track closely, attend, or act immediately.
The "act immediately" bucket is genuinely small when you apply SSVC correctly. We're talking single digits to low double digits of CVEs per scan cycle in most environments, rather than hundreds of "Criticals." That's actionable. Your team can actually respond to that within a short window without destroying their change management process or skipping testing.
Asset criticality weighting, which any mature vulnerability management program should have, feeds directly into the SSVC mission impact decision point. A CVE on your customer-facing payment processing system is not the same as the same CVE on an isolated internal wiki server that three people use. Treating them identically — which flat CVSS-based SLAs do — means you're either over-investing in protecting low-value assets or under-protecting high-value ones, often both simultaneously.
Building an asset criticality model doesn't have to be complicated. A simple tiering — business critical (customer-facing, revenue-generating, PII-handling), internal critical (authentication infrastructure, CI/CD pipeline, security tooling), standard, and dev/test — gives you enough differentiation to make meaningfully different patching decisions. Your crown jewels get the emergency change window. Your dev environment gets the next scheduled maintenance window. That's not novel, but it's remarkable how few programs actually formalize it.
What "100% Patch Compliance" Actually Means
Nothing. It means nothing. Or more precisely, it means nothing about security outcomes.
Patch compliance is an operational metric. It tells you how well your patching process executed against a defined policy. It tells you nothing about whether the vulnerabilities that matter were closed, whether new vulnerabilities were introduced by the patching process itself, whether the assets that are in compliance are the assets that adversaries actually care about, or whether your exception list is quietly accumulating all the risk your compliance number is shedding.
The organizations I've seen with the best-looking compliance dashboards often have the most dysfunction underneath. The metric gets gamed, consciously or not. Scan schedules get adjusted so that patching windows happen just before scans. Assets that repeatedly fail patching get put in a "remediation tracking" category that's separate from the compliance calculation. Exceptions get approved by people who have no visibility into cumulative risk. The number looks good because everyone involved is being measured on the number.
What would a meaningful metric look like? Mean time to remediate for KEV-listed CVEs, broken out by asset tier. Percentage of SSVC "act immediately" items closed within defined windows. Reduction in exploitable attack surface on internet-facing assets over a rolling 90-day period. None of those are as clean as "94% compliant," which is probably why they don't make it onto executive dashboards.
The Linux Live Patching Thing is Real and You Should Know About It
One specific piece of operational reality that doesn't get enough coverage in vulnerability management discussions: kernel live patching on Linux has gotten genuinely good and most organizations aren't using it.
kpatch on RHEL/CentOS and Canonical's livepatch on Ubuntu allow you to apply kernel security patches without rebooting. The Linux kernel is patched in memory while it's running. For high-uptime infrastructure — database servers, hypervisors, anything where a reboot requires a meaningful change management process and business approval — this removes a huge constraint from the kernel patching decision. The excuse "we can't reboot that server for another six weeks" evaporates for kernel-level CVEs.
Is it magic? No. There are patch types that can't be live-patched, and you'll still accumulate deferred patches that require eventual reboots. But for the category of "critical kernel CVE that we'd normally sit on for weeks because the reboot window is far away," live patching is a legitimate operational tool that directly improves your security posture on Linux infrastructure without the business disruption that makes patching politically difficult.
Red Hat includes this in RHEL subscriptions. Canonical sells it as Ubuntu Advantage. The tooling is mature. If you manage significant Linux infrastructure and you're not using kernel live patching, that's a conversation worth having with your team.
Getting Off the Treadmill
You don't fix this with more tooling. You fix it by changing what you're optimizing for.
Stop optimizing for patch compliance percentage. Start optimizing for reduction in exploitable risk on assets adversaries actually want. That means you need a threat model — even a rough one — that tells you what your high-value targets are and what threat actors care about your sector. It means your vulnerability prioritization needs to incorporate real exploitation data (EPSS, KEV) rather than theoretical severity scoring. It means your asset inventory needs to be accurate enough to trust, which is an ongoing process not a one-time project. And it means your exceptions need to be visible, time-bounded, and compensating-controlled rather than quietly parking risk in a spreadsheet tab nobody reviews.
The treadmill feels safe because it's measurable and auditors like it. Risk-based vulnerability management is messier to report on and requires your team to make judgment calls rather than follow a policy chart. But the judgment calls are closer to what security actually requires. The treadmill just keeps you busy.
