Why CVSS Is Not the Metric You’re Looking For

Published:

7 min read

Why CVSS Is Not the Metric You’re Looking For (and What to Do About It)

Let’s talk about one of the sacred cows in the cybersecurity world (next to the Pyramide of Pain): CVSS, the Common Vulnerability Scoring System. For years, it’s been the go-to metric for prioritizing vulnerabilities. But what if I told you it’s not the holy grail it’s made out to be? In fact, recent examples prove it can mislead us when it matters most. It’s time to call it like it is: we need to stop using CVSS as the primary tool for vulnerability prioritization. The following sections will explain why and what we should could do instead.

CVSS: A Great Idea That Doesn’t Quite Work

On paper, CVSS is brilliant. It gives us a standardized way to measure vulnerability severity. But in practice, it’s like judging the strength of your coffee by the color alone. Sure, a CVSS score gives you numbers (oooh, decimals!), but those numbers can be wildly misleading.

Take the temporal base score — a factor that considers whether a patch exists. Sounds practical, right? Wrong. As a company, or as indivdual for what its worth, I don’t care if there’s a patch. (Well I do care, but keep on reading.) I care about the chaos that vulnerability can unleash before I apply that patch. My systems don’t magically become safe because someone somewhere released a fix. Until it’s rolled out in my environment, I’m still vulnerable. Period.

Why CVSS Doesn’t Tell the Whole Story

CVSS is too focused on a one-size-fits-all approach. It doesn’t consider the unique context of your company:

CVSS v3.1 vs. v4: New Version, Same Old Problems

So, CVSS got an upgrade..which was relased on Novmeber 2023! Maybe someone should tell NVD or the majority of vendors still using v3.1.

In CVSS v4, we’ve got shiny new features like Exploit Maturity, Functional Impact, and Harm to Individuals. These additions are supposed to bring more nuance to scoring, making it feel less like a blunt instrument and more like a scalpel. Cool, right? Except… it’s still CVSS, and it still relies on a whole lot of guesswork.

For instance, v4 lets you score vulnerabilities differently depending on whether they affect individuals versus businesses. That’s great for academic discussions, but when your sysadmin is knee-deep in patching, do you think they’re pondering the philosophical differences between “Functional Impact” and “Safety Impact”? Nope, they just want to know what’s going to blow up first.

And let’s not forget: even with these changes, CVSS v4 is still vulnerable (pun intended) to vendor interpretation. If vendors were fudging scores with v3.1, do we really think they’ll suddenly start playing fair with v4? Not likely.

The “Exploit Maturity” Shenanigans: A Tale of Two Scores

Let’s talk about one of CVSS v4’s fancy new features: Exploit Maturity. On paper, it sounds useful—score adjustments based on how “ready” an exploit is in the wild. But in practice, it’s yet another example of a small tweak with a massive ripple effect.

Take these two scoring examples:

The only difference? The Exploit Maturity value: Attacked (E:A) versus Unreported (E:U). One small toggle, and suddenly your vulnerability drops from a hair-on-fire 9.3 to a slightly more chill 8.1.

Here’s the kicker: if the vendor misjudges exploit maturity (and let’s face it, that happens), you might completely overlook this vulnerability. Why? Because your team decided—after hours of deliberation with 15 people in a conference room and some overly complex Excel magic—that your emergency patching threshold is 8.6. That misjudged “High” score? It flies under the radar, and you’re left exposed.

So now you’re stuck playing vulnerability roulette because of a single subjective factor. Fun, right? Turns out, Exploit Maturity adds nuance, sure, but also a new way for vendors (and your own team) to accidentally deprioritize something critical.

Lesson learned? Maybe don’t let one checkbox determine whether you stay up all night patching—or sleep soundly while your systems are under attack.

The 9.8 Mystery: Why Not Go All the Way to 10?

Ever noticed how vendors love to slap a 9.8 on critical vulnerabilities instead of the full-blown, apocalyptic 10? It’s like they’re allergic to double digits, and while it might seem trivial, there’s a not-so-reassuring reason behind it.

In CVSS v3.1, the difference between a 9.8 and a 10 can come down to a single toggle: Scope (S). That’s it. Check this out:

The only difference? S:U (Unchanged) versus S:C (Changed). That’s it—a simple toggle. Yet this tiny distinction can mean the difference between “red alert, patch NOW” and “eh, it’s still critical, but maybe we’ve got a bit more time.”

But here’s the kicker: how many security teams even notice this nuance? And how many vendors rely on this toggle to sidestep the psychological impact of calling something a full 10? By tweaking Scope, they can make a vulnerability seem a little less urgent—at least on paper.

The lesson here? Don’t get distracted by the numbers alone. Whether it’s a 9.8 or a 10, if it’s critical, it’s critical. Treat it like the high-priority fire drill it probably is, toggle or no toggle.

Stop Chasing Scores. Start Prioritizing Context.

So, what’s the alternative? Throw out the CVSS calculator and take a more holistic approach to prioritization:

  1. Focus on Exploitability: Is this vulnerability actively being exploited in the wild? If the answer is yes, drop everything and patch it. (I know what you want to say, keep reading.)

  2. Assess Environmental Impact: What systems, applications, or data does this vulnerability touch? If it’s connected to business-critical assets, it goes to the top of the list.

  3. Use Threat Intelligence: Are attackers targeting companies in your industry or region? If so, this vulnerability should get your immediate attention. Do we know from previous incidents that similar vulnerabilities will be exploited in no time? (Confluence, anyone?)

  4. Monitor Internal Signals: Look for signs that the vulnerability might already be exploited within your environment. Alerts from endpoint detection or unusual traffic patterns should raise red flags. It for sure is not true for any vendor, but will you trust the words of a crappy vendor producing crappy security in their apps in first place to understand the actual threat landscape?

Conclusion: The Hard Truth About Vulnerability Management

Yes, life would be easier if we could just follow some magic numbers and call it a day. But the reality hits hard—really hard—when your business grinds to a halt because of a vulnerability that could have been patched on Friday, but the allure of waiting until Monday was just too tempting. Spoiler alert: attackers don’t take weekends off. They usually have better automations in place than you do.

Sure, the proposed way is more challenging. It’s tougher to dig into the context, evaluate risks beyond scores, and make judgment calls. But that’s exactly why you hire experts, people who live and breathe this stuff to equip your Vulnerability Management team with the insights and assessments they need to spot and prioritize those sneaky, non-standard vulnerabilities. Of course, this only works if you’ve got a solid (and functional) patching process in place to act on those insights.

In the end, it’s up to you to decide if it’s worth it. Do you invest in a skilled team to protect your business proactively, or do you roll the dice and hope your infrastructure doesn’t get hijacked? Spoiler alert: experts cost money, but so does ransomware and one of those is a lot harder to recover from. Choose wisely.