Picture this: You’re a security program manager at a financial services company. Last quarter, your team crushed it. Patching velocity was up, you closed 250 critical and high findings, and your dashboard trend lines all point in the right direction. Then your director asks the question you’ve been dodging: “Are we actually safer than we were three months ago?”
And you freeze.
Because you can report SLA compliance rates. You can show average time-to-close metrics. What you can’t do is answer whether those 250 patched vulnerabilities were the ones that mattered, or whether the 600 still sitting in your backlog include the one that gets you breached next quarter.
This scenario, pulled from a recent r/ITManagers thread, isn’t an isolated incident. It’s the dirty secret of modern security operations: we’re measuring activity, not risk reduction. The metrics we worship tell us how fast we’re moving, not whether we’re moving toward anything meaningful.
The Activity Trap: When Metrics Become the Mission
Here’s the uncomfortable reality: security teams have built elaborate reporting systems around metrics that feel rigorous but deliver almost zero insight into actual security posture. Patching velocity, SLA compliance, closure rates, these are operational metrics. They measure whether your team is busy, not whether your organization is safer.
The distinction matters because it drives behavior. When teams are measured on closure rates, they optimize for closure rates. That means patching whatever’s easiest, whatever’s been sitting longest, or whatever the scanner screams loudest about, regardless of whether it actually matters for your organization’s risk profile.
This isn’t a minor measurement issue. It’s a fundamental misalignment between what we track and what we need to know. As one security professional put it in the thread: “CVSS score alone tells you nothing about whether you should panic. A 9.8 on a customer-facing production server is a fire drill. A 9.8 on a dev box that gets rebuilt every night is just another day in the office.”
The problem? Most scanners paint them the same way.
Why “We Patched More” Doesn’t Equal “We’re Safer”
Let’s dig into the math that should terrify you. Your organization has 850 critical and high vulnerabilities. You patch 250 of them. On the surface, that’s a 30% improvement. But here’s the question nobody asks: what if those 850 included 100 vulnerabilities on systems that have never touched the internet, never store sensitive data, and never appear in any attack path?
And what if the 600 remaining include a handful of internet-facing, business-critical systems with known exploits being actively weaponized?
Your “30% improvement” just became meaningless. You might even be worse off than before, because you’ve created a false sense of progress that will be used to justify budget allocation, resource deployment, and risk acceptance decisions.
The counterargument from the thread is worth taking seriously: “There is no world where having 850 unpatched vulnerabilities is the same risk factor as 600 unpatched vulnerabilities with 250 being patched. You’re definitively in a better position.”
That’s true in the narrowest mathematical sense. But it misses the point. The question isn’t whether you’re “better off” than a hypothetical past version of yourself. It’s whether you’re better off than you need to be, and whether your patching efforts are proportionally reducing the risks that could actually hurt you.
The Asset Context Problem: Not All CVEs Are Created Equal
Here’s where the conversation gets real. The core flaw in most vulnerability management programs is treating every critical finding with equal urgency. A 9.8 CVSS on a production server processing customer payments is fundamentally different from a 9.8 on an internal dev box that gets rebuilt every night.
The CVSS score itself is part of the problem. As the baramundi analysis points out, CVSS provides “a standardized score for the technical severity of vulnerabilities”, but technical severity isn’t business risk. The score says nothing about whether the affected system is internet-facing, whether it supports critical operations, or whether compensating controls are already in place.
This becomes even more critical when you consider that AI is dramatically accelerating both vulnerability discovery and exploitation. The reality is stark: every publicly published vulnerability is now cycling through AI attack chains within days, if not hours. Patching the “easy” stuff while critical infrastructure remains exposed isn’t just suboptimal, it’s actively dangerous, a real-world example of undetected propagation due to misplaced trust in tools.
Moving from Vulnerability Management to Exposure Management
The solution isn’t to stop tracking metrics. It’s to track the right ones. Industry practitioners increasingly advocate shifting from vulnerability management, which catalogs and patches based on severity scores, to exposure management, which prioritizes based on actual attack paths, business criticality, and exploit likelihood.
This isn’t just semantics. It’s a fundamental shift in how you allocate resources. Exposure management asks questions like:
- Is this asset reachable from the internet?
- Does it connect to systems that matter?
- Is this vulnerability currently being exploited?
- What business process depends on this system?
The distinction between ASM and exposure management is crucial: “ASM helps answer ‘What is exposed?’ Exposure management helps answer ‘Which exposures matter most, and what should we change first?'”
Practitioners who’ve made this shift report dramatic differences in how they can communicate risk to leadership. Instead of “we patched 250 CVEs”, it becomes “we reduced risk on critical production assets by X percent this quarter.” The second statement lands differently in a board meeting because it demonstrates business impact, not just technical activity.
The CISA KEV Catalog: Your New Best Friend
One of the most underutilized resources in vulnerability prioritization is the CISA Known Exploited Vulnerabilities (KEV) catalog. This authoritative source tracks vulnerabilities that are actually being exploited in the wild, not theoretical risks, not CVSS score inflation, but real, active exploitation.
Here’s the thing: there are currently 1,661 entries in the KEV catalog. That’s your real priority list. If a vulnerability isn’t being actively exploited, it might still matter, but it almost certainly deserves lower priority than one that is. The catalog should be your starting point for any risk-based prioritization conversation.
CISA’s Binding Operational Directive 26-04 even requires federal agencies to patch KEV-listed vulnerabilities within specific timeframes based on risk. Your organization should be even more aggressive. If a vulnerability is on this list and affects your environment, that’s your first patching target, regardless of what CVSS says.
Building Metrics That Actually Measure Safety
So what should you actually track? Based on the practitioner discussion and industry analysis, here’s what a meaningful security metrics program looks like:
Risk exposure score. Instead of raw vulnerability counts, calculate a weighted score that accounts for asset criticality, internet exposure, and exploit likelihood. This gives you a trending line that actually means something.
Crown jewel coverage. Track how many critical business systems have zero known exploitable vulnerabilities. This is a concrete, defensible metric.
Mean time to remediate (MTTR) for exploited vulnerabilities. How fast do you close out KEV-listed vulnerabilities? This is the metric that correlates with breach likelihood.
Compensating control effectiveness. For vulnerabilities you can’t patch immediately, are your compensating controls actually working? Track detection and prevention rates.
Backlog risk distribution. Don’t just count backlog items. Show what percentage of your backlog touches internet-facing systems, production environments, or high-value assets.
The CVE grading discussion at MSSP Alert emphasizes something crucial: “Security teams need signal, not just severity.” The future of vulnerability management won’t be won by tracking the most CVEs. It’ll be won by teams that can turn noisy data into defensible action.
The Executive Communication Problem
Part of this challenge is linguistic. When a director asks “are we safer?”, they’re asking a business question, not a technical one. They want to know: are we less likely to experience a damaging breach? Can we defend this position to regulators, auditors, and the board?
The instinct to hedge is understandable. Nobody wants to guarantee safety they can’t prove. But the conversation needs to shift from defensiveness to framing. As one commenter put it: “We started with 850 critical/high vulnerabilities and resolved 30% of those. Are we safer? Yes. Are we safe? No, but our pursuit of that continues.”
That framing is honest AND persuasive. It acknowledges progress without claiming perfection. It reframes security as a continuous journey rather than a destination. And it gives leadership the language they need to discuss risk with the board.
Where AI and Automation Fit
The rise of agentic security platforms, like Discern Security’s recent $13M Series A for their “Security Loop”, points toward a future where metrics and remediation become more tightly coupled. These tools promise to continuously identify control gaps, prioritize based on business context, and coordinate remediation across teams.
The potential is real. As one cybersecurity architect noted: “I see a huge opportunity to tangibly and quantifiably improve security metrics and posture with AI loops where we can assess, baseline, optimize, and remediate controls over time.”
But here’s the caveat that should make you cautious: AI can help you close gaps faster, but it can’t tell you which gaps matter if your foundational data is wrong. Garbage in, garbage out applies to security AIs just as much as it applies to how models game flawed evaluations, paralleling security metric manipulation.
The Bottom Line
Your patching metrics aren’t worthless, they’re just incomplete. They tell you whether your team is busy, not whether your organization is safer.
The path forward starts with honest acknowledgment: if you can’t answer the safety question, your metrics are measuring activity, not outcomes. Then comes the harder work of building exposure-based metrics that account for asset context, exploit likelihood, and business criticality.
The security teams that thrive in the AI era won’t be the ones with the highest patching velocity. They’ll be the ones who can walk into a board meeting and answer the question that actually matters: “Are we safer than we were last quarter?”
And if you can’t answer that yet? Start building the metrics that will let you. The conversation about how superficial system design creates false confidence in safety is especially relevant here, your dashboard should reflect reality, not comfort. Your future security posture depends on it.