|
Getting your Trinity Audio player ready...
|
Overview
I’ve sat in a lot of vulnerability reviews where the team felt good about the numbers. Closed tickets for high-CVSS CVEs were up. Critical findings were down. And then came the inevitable incident – the one the CVE count never saw coming. It’s a pattern I’ve seen more times than I’d prefer. It points to a fundamental problem with how most organizations still measure risk. And in most cases, the teams running these programs already sense it – they’re just constrained by the audits, tooling, and staffing realities they’re working within.
The CVE count and CVSS scores remain the default language of vulnerability management. Yet neither one tells you whether you’re actually reducing exposure. That disconnect is more widespread than most teams realize. In this blog, I’ll explain why the CVE count fails as a risk metric, why the behavior persists, and what a more meaningful measure looks like.
The Score Survives; the Context Doesn’t
A vulnerability that’s scored 9.8 in a non-production environment with no external access will float to the top of most dashboards. A 7.2-rated flaw in a public-facing authentication API supporting millions of users will sit lower in the queue. One is technically severe. The other is strategically dangerous. But 9.8 is greater than 7.2, no matter the context.
This is exactly where CVSS scores fall flat. CVSS measures the theoretical severity of a vulnerability in isolation, not the risk that vulnerability creates in your specific environment. Research from FIRST – the organization that maintains the CVSS standard – found that of all CVEs scored 7.0 or higher, only about 4% were observed in exploitation attempts. This means that the vast majority of what teams treat as their highest priority are leads that no attacker is actively pursuing.
I’ve seen teams build their entire remediation programs around CVSS thresholds – a policy like “remediate all critical vulnerabilities within seven days” – and treat that as a rigorous risk management process. It sounds defensible until you realize the policy says nothing about whether those vulnerabilities are reachable, exploitable, or connected to anything an attacker would actually want.
When findings get logged into ticketing systems, the severity score makes it into the ticket. Everything else – asset context, network exposure, exploit path – doesn’t. The result is what The Hacker News recently called “severity theater”: the organization looks busy, leadership gets a report full of positive trend lines…while an exposure rated 6.8 that actually threatens the business remains untouched.
The Volume Problem
In 2026, analysts are forecasting some 59,427 new CVEs – the first year the industry is expected to surpass 50,000. That’s more than 160 new vulnerabilities every single day. No team can patch their way through that. And those that try end up with a backlog measured in months and a to-do list that grows faster than they can keep up with.
Given recent news, that forecast may be conservative. Anthropic’s Mythos model is already autonomously discovering vulnerabilities at a scale no human team can match – including complex attack paths that single-source scanners and manual reviews miss entirely. That CVE forecast did not account for Mythos or other AI-driven discovery tools. And every one of those AI-generated findings lands in the same remediation queue, scored by a system that is buckling under the weight.
In April this year, NIST announced that the National Vulnerability Database will no longer enrich all published CVEs. Only vulnerabilities in CISA’s KEV catalog, federal software, and critical software under Executive Order 14028 will be fully analyzed. Everything else moves to a “Not Scheduled” status. That means that programs that depend on NVD enrichment to populate their dashboards and drive their SLAs are already operating on incomplete data.
And there’s a deeper problem: what the volume of CVEs conceals. Just 1% of CVEs were exploited in the wild in 2025. A CVE count doesn’t distinguish between a vulnerability that leads nowhere and one that sits on a direct path to your most critical assets. Attackers make that distinction immediately. Most vulnerability programs still don’t.
Why the Behavior Persists
It would be easy to chalk the persistence of CVSS-based prioritization up to market inertia or habit, but in my experience the causes are more entrenched than that.
CVSS is written into compliance requirements that most organizations can’t opt out of. PCI DSS requires that all external vulnerabilities with a CVSS score of 4.0 or higher be addressed within a three-month scan window, regardless of environmental risk context. FedRAMP requires that vulnerability scanning outputs use CVSS as the original risk rating. When your audit depends on the number, the number becomes the program.
What starts as a compliance mandate filters down to security culture. Most organizations still rely solely on CVSS, partly because calculating environmental or contextual metrics is more difficult at scale. What’s more, remediation speeds generally don’t differ greatly between vulnerabilities with known exploits and those without. That tells me that exploit status isn’t actually driving the process. The severity score is. And that is the definition of a program optimizing itself for the wrong signals.
What the Count Can’t See
CVEs cover identifiable software vulnerabilities. That’s a meaningful slice of the attack surface – but it’s only a slice. Misconfigurations, over-permissioned identities, cached credentials, lateral movement paths and much more – none of these have CVEs. They don’t appear in scanner output, they don’t inflate your CVE count, and they don’t trigger your CVSS-based SLAs.
They do, however, give attackers everything they need to move through your environment and reach your critical assets.
The breach record from 2025 reinforces this. The M&S ransomware incident traced back to social engineering and Active Directory credential theft – no high-severity CVE required. The TransUnion breach exposed 4.4 million records through misconfigured API permissions in a third-party Salesforce integration. Blue Shield of California leaked the data of 4.7 million members through a misconfigured analytics tracking pixel. In each case, the entry point was an exposure that no vulnerability scanner would have flagged.
What a Better Metric Looks Like
So, what does a more useful metric actually look like? The question worth asking isn’t how many CVEs your team closed this quarter – it’s how many viable attack paths to your critical assets still exist.
This is exactly the shift Continuous Exposure Management is designed to facilitate – from periodic reporting against a vulnerability list to continuous validation of whether your controls actually block the paths attackers would take. That’s a metric with real meaning for leadership, and a much more accurate reflection of whether the work your team is doing is actually making the organization safer.
Need a practical test? The fastest way to see if you need to update your exposure management capabilities is to ask your team: “How many of our critical assets have a validated attack path from an internet-facing entry point? How has that number changed quarter over quarter? What percentage of our remediation effort closed an actual path versus a theoretical finding?”
If you don’t like the answers you get, we can help.
