Why we shouldn't treat the CVSS base score as gospel

On Sept. 6, Cisco issued an urgent fix for an authentication bypass flaw affecting the single sign-on (SSO) implementation of its BroadWorks application delivery platform and BroadWorks Xtended Services Platform: a bug that topped out at the maximum CVSS severity rating of 10.0. 

And thus did CVE-2023-20238 get dumped onto the backs of overwhelmed security teams, merging with  an unrelenting torrent of Common Vulnerabilities and Exposures (CVEs) that, as of 2022, was up 59% year over year. According to a recent analysis, fresh CVEs are being pumped out at an average of one every 20 minutes, highlighting the fact that few organizations can hope to plow themselves out from under the Sisyphean pile of ever-growing vulnerability backlogs. 

Part of the problem, say some, is that the way that people are using the CVSS score — the Common Vulnerability Scoring System, which has come to be the de facto measuring stick regarding the criticality of a technology system’s bugs — is broken. 

Contrast Security Chief Information Security Officer (CISO) David Lindner is one of them. In his Aug. 18 CISO Insights column, he contends that, as a tool to measure risk, the CVSS “doesn’t work and is extremely broken.” We should, as an industry, move away from using just the CVSS base score, he says. 

He contends that the main problem is lack of context. How did CVE-2023-20238 get the maximum “critical” score of 10.0? For that matter, how does any vulnerability get its ranking? 

Unfortunately, Lindner says, the ranking is subjective. “I'm going to say that 99.9% of the time, these CVEs are ranked based on worst-case scenarios,” he says. “Everything is worst-case scenario. We get 80 CVEs released per day, or whatever the number is.” The number, of course, varies widely. As of Friday, Sept. 8, 2:38 p.m. EST, NIST’s NVD dashboard had recorded 439 new CVEs as being received and processed that week. According to the CVE.ICU project from researcher Jerry Gamblin, as of Sept. 11, the average CVSS score of all CVEs created in 2023 was 7.19: a rating that’s considered high. 

Source: Researcher Jerry Gamblin’s CVE.ICU project.

“They're all rated in a worst-case scenario. And then we, as security practitioners, are  expected to fix them based on our vulnerability management matrix needing to fix a critical CVE in XYZ time, whatever that might be — say, 7 days or 30 days, depending on your program,” Lindner says.

Your critical is not my critical

But the reality is that, just because a CVSS score reflects someone's worst-case scenario, doesn’t mean that it’s critical for you. CVSS scores are missing important factors, Lindner explains, including, Is this CVE being exploited? Is there a public exploit available? “There are so many other factors that aren't part of that rating,” he says. 

At the same time, regulations such a FedRAMP require organizations to follow these risk rankings, which are, again, worst-case scenarios that neglect to factor in whether or not CVEs are a threat to a given organization, Lindner says. “Just because we’re seeing ~80 CVEs/day doesn’t mean there are 80 worst-case scenarios — i.e., exploits available, exploits being conducted — of 80 bugs/day.

“I'm sorry, we just don't,” Lindner says. “They're not being attacked. I think the latest number was like, 2% of any CVE has public exploit code.* There's no public exploit code. The likelihood of you being attacked is, like, 0. Regardless, it's going to be ranked 9, ‘critical,’ and we have to go fix it in 7 days according to our internal process.”

(*According to Carnegie Mellon University,  4.1+/-0.1% of CVE-IDs have public exploit code associated with them within 365 days.) 

Will CVSS 4.0 bail us out?

Besides being overly subjective, the widely adopted CVSS has also been criticized for an overly complex scoring approach and for wide misuse in vulnerability prioritization. 

There’s change afoot, however: The CVSS Special Interest Group (CVSS SIG) will officially release a new version, CVSS 4.0, on Oct. 1, 2023. It’s currently in a public preview and comment period.

To help address the lack of additional metrics in vulnerability calculations, CVSS 4.0 will introduce new nomenclatures, including CVSS-B: CVSS Base Score, CVSS-BT: CVSS Base + Threat Score, CVSS-BE: Base + Environmental Score, andnCVSS-BTE: CVSS Base + Threat + Environmental Score. As well, the release will include a new base metric titled Attack Requirements (AT), an update to the User Interaction (UI) metric and retiring of the Scope (S) base metric. 

These are “things that  people should be taking into account when they're getting these CVEs,” Lindner says. 

CVSS 4.0 won’t be perfect, mind you. The CISO gave this example of why: Suppose there's a critical CVE in the Java Spring application framework. There’s no available public exploit. However, the rating factors include confidentiality, integrity and availability. Let’s say this hypothetical CVE is rated “high” for confidentiality, meaning that it could lead to a breach of data confidentiality. 

But what if that data isn’t actually sensitive? What if it’s data coming out of a lunch menu application running in the local high school in an antiquated version of Spring? 

It just doesn’t matter that Tuesday’s lunch data will be exposed as “kebabs.” 

But in such a case, it doesn’t matter that confidentiality isn't important. “I don't get the chance to factor that in,” Lindner notes. “I still have a critical vulnerability that I have to go and drop everything and fix. … which creates all this angst between security and development teams and everyone else in between. It's creating more headaches for people than they know what to do with. So they all just fall back: ‘All right, fine,’ security teams say. ‘We'll just follow what they want us to do and fix them.’”

The CVSS rating was created back in the days when there were a third, or less, of the current number of CVEs. The number of CVEs isn’t going to get any better any time soon, what with the billions and billions and billions of lines of code and software written every year — particularly not now, with generative AI constantly building more code. 

“It's just frustrating,” Lindner sighs. “And it's hard. Contrast, as a company, we want to push the envelope and push people to a better approach to the way that they're doing security. And one of the important factors is, How do you rank risk? And how do you figure all that stuff out? 

“We try to expose more of that sort of data to folks, so they can make a little bit more intelligent decision on when and what they should fix.”