The CVSS (Common Vulnerability Scoring System) is facing significant pushback as both the cURL project and Go security teams are publicly distance themselves from the framework. While CVSS is designed to assign a severity score to vulnerabilities, its one-size-fits-all approach often produces misleading results, particularly for projects like cURL, which operates across diverse environments and billions of installations.
Why CVSS Falls Short#
In a post titled “CVSS is dead to us”, Daniel Stenberg, creator of cURL, explains how CVSS fails to account for the specific contexts of vulnerabilities, leading to inflated or inaccurate scores. This problem was recently illustrated when CISA assigned a critical CVSS 9.1 score to a cURL vulnerability (CVE-2024-11053) that the cURL team deemed low severity. Such mismatches fuel misinformation, overloading maintainers and confusing users.
“The CVSS scoring is really designed for when you know exactly when and how the product is used and how an exploit of the flaw affects it,” Stenberg said. “Then it might at least work. For a generic code base shipped in a tarball that runs in more than twenty billion installations it does less so.
“The team of actual experts who knows this code and perfectly understands the security problem says LOW. The team at CISA overrides that and insists that are all wrong and that this problem risks breaking the Internet. Because we apparently need a CVSS at all costs.”
The Go security team has echoed these sentiments, opting for context-driven severity assessments over CVSS scores. Both teams advocate for flexible, nuanced approaches to vulnerability disclosure, challenging the industry's reliance on CVSS as a universal standard.
These developments spotlight growing dissatisfaction with CVSS and its role in modern vulnerability management, pushing the industry toward more effective alternatives.
Challenging the Context-Driven Approach#
While the cURL and Go security teams have chosen to move away from CVSS scoring, not everyone agrees that their context-driven approach is the right solution. One commenter on the cURL blog raises an important counterpoint:
Given you have no control how your project is used, what gives you confidence that your guesses are even vaguely correct? I think the problem for cURL is that people likely have widely differing use cases. For some, a bug may well be critical; for others, the issue will be zero. CVSS is supposed to give a single score.
This perspective highlights a key challenge for maintainers of projects like cURL: balancing the need to communicate nuanced information with the broader ecosystem's demand for standardized metrics.
“More than a want – orgs NEED to be able to show they did something to make their insurer happy, and to show in court when they inevitably get hacked,” Michael Kohne commented on Stenberg’s post.
When asked on LinkedIn about an alternative, Stenberg responded, “If there would be any easy answers, I would offer some…”
Jay Jacobs, founder at Empirical Security, suggested that Stenberg may be placing the blame in the wrong direction.
“CVE records do not require CVSS and there is enrichment on the data because there are endless choirs of complaints that a vulnerability record without CVSS is an incomplete record,” Jacobs commented on LinkedIn. “Like it or not, consumers want an estimate of risk they trust, and CVSS is the de facto standard on that front.
“I’m not defending CVSS here, it’s inflated, overused and misused. But history is littered with countless versions of misguided risk ratings on ordinal scales and even if you had a risk rating system covered in gold, people would still ask, “but what’s the CVSS score?”
The Culture Clash Between Security Researchers and Open Source Maintainers#
This increased scrutiny on the inaccuracy of CVSS scores is another example of security theater that burdens open source maintainers.
“When you are a community open source maintainer, it can feel like the boy who cried wolf with all the emails you get from researchers,” Mike McNeil commented on LinkedIn.
“A never ending front of wasted time, that occasionally, RARELY, is actually vulnerability. I share your perspective on CVSS. But a bit deeper, there’s a culture clash between security researchers and open source maintainers.”
McNeil observed that bug bounties are “the cool hobby of researchers,” who are rewarded when they receive recognition from maintainers.
“But when you’re unpaid, and 9/10 of the emails are about trivial vulns in method calls from dependencies that you’ve proven none of your code paths touch, and where patching would require a breaking change that means you are now fixing compatibility in ANOTHER open source project… well, it can get frustrating,” he said.
“The researcher is often trying to make sure they get credit, and that can lead to extremes like public attacks when they feel that a vuln is significant, but the project’s maintainers have proven it is not significant.”
Nikos Mavrogiannopoulos described using CVSS in open source as a focus on isolated flaws that misses the bigger picture, where tools like CVSS assign undue importance to minor vulnerabilities without considering their broader impact on the overall security of a system.
“Using CVSS to measure the risk of an exploit in open-source backend software is like assessing the risk of a single brick breaking in an apartment building,” Mavrogiannopoulos commented on LinkedIn. “On its own, it doesn't provide insight into what you are interested at; the overall vulnerability of the building.
NVD’s Decline and the Backlog Problem#
The National Vulnerability Database (NVD), once a trusted source for enriched CVE data, has struggled in recent years with a significant backlog of CVEs missing critical enrichment, including CVSS scores. As the volume of published CVEs has grown—exceeding 40,000 annually—NVD has been unable to keep up. This has led to delays in processing vulnerabilities, leaving organizations without the detailed information they rely on to assess risk.
CISA stepped in to take over this responsibility as an Authorized Data Publisher (ADP), aiming to address gaps in enrichment. However, the transition has not solved the underlying issues. The process remains flawed, as demonstrated by arbitrary CVSS scoring that often lacks context or understanding of the affected software. These scores are quickly generated through automated calculations and applied broadly, resulting in misleading risk assessments.
This backlog and the subsequent reliance on rushed enrichment further undermine the credibility of the CVSS framework. Security teams that depend on accurate and timely data are often left grappling with outdated or incorrect scores, compounding the challenges of managing vulnerabilities effectively.
“It’s not like CISA gets overloaded by worried users when they do this,” Stenberg said. “Their incompetence here puts a load on no one else but the curl project. But sure, they got their CVSS added.”
Rethinking CVSS for Modern Security Needs#
These developments spotlight growing dissatisfaction with CVSS and highlight the broader challenges of vulnerability management in an increasingly complex ecosystem. As projects like cURL and Go reject CVSS in favor of context-aware approaches, the industry must reevaluate its reliance on outdated standards and address systemic issues to effectively address modern security challenges.