CVSS Is Dead to Us(daniel.haxx.se)
daniel.haxx.se
CVSS Is Dead to Us
https://daniel.haxx.se/blog/2025/01/23/cvss-is-dead-to-us/
13 comments
Agreed. That being said, the CVSS calculator is useful for reminding you of factors that you may not have included in your analysis.
We must do something! This is something! Therefore we must do it!
That fucking mindset is what's going to kill the internet. I'm glad Daniel is resisting but like he says, he's but a small cog in a machine that's run by bean-counting idiots.
That fucking mindset is what's going to kill the internet. I'm glad Daniel is resisting but like he says, he's but a small cog in a machine that's run by bean-counting idiots.
These bullshit “security scans” are disruptive and barely more than box checking exercises by alleged “cyber security” people.
I’ve seen entire companies cripple themselves with this security theatre for days on end requiring usually some executive interjection to break the deadlock.
Instead of applying nuance, it’s all black and white. I once experienced at a job not being able to deploy urgent hot fixes even for live production issues impacting customers.
Reason? The useless DevOps team introduced some automated security scanner which found a single reported vulnerability in a development tool. A tool that in no way reaches the users browser or the servers.
Bear in mind this was a brand new found vulnerability and there was no fix yet.
But because of that, and because of their lack of understanding, and their insistence we were just being stubborn and not believing us when we told them there is literally no fix available yet, they disabled our ability to deploy anything.
While the urgent fix for production was already committed and merged ready to be deployed.
It took great managerial pomp and fanfare to get that abolished.
I’d imagine there’s a great deal of pressure on OSS maintainers when these borderline CVEs get published.
I’ve seen entire companies cripple themselves with this security theatre for days on end requiring usually some executive interjection to break the deadlock.
Instead of applying nuance, it’s all black and white. I once experienced at a job not being able to deploy urgent hot fixes even for live production issues impacting customers.
Reason? The useless DevOps team introduced some automated security scanner which found a single reported vulnerability in a development tool. A tool that in no way reaches the users browser or the servers.
Bear in mind this was a brand new found vulnerability and there was no fix yet.
But because of that, and because of their lack of understanding, and their insistence we were just being stubborn and not believing us when we told them there is literally no fix available yet, they disabled our ability to deploy anything.
While the urgent fix for production was already committed and merged ready to be deployed.
It took great managerial pomp and fanfare to get that abolished.
I’d imagine there’s a great deal of pressure on OSS maintainers when these borderline CVEs get published.
I feel you. These "cyber security" people's main qualification appears to be scoring 70% on a multiple choice test. I've seen people with no practical experience building things be paid more than 25+ year veterans (who, by the way, might know a thing or two about security).
The CIO and CISO don't understand that certifications only tell you someone is minimally qualified (at best). They are afraid of what they don't know (which is everything) and looking for something to conform to, some external authority on which to base their cargo cult. But they don't want to learn anything more complicated than a buzzword, so their first and last interview question for a security candidate is "what is the CIA triad?"
The old timers don't seem particularly anxious about security (because they understand where and how the rubber meets the road), which is misinterpreted as complacency.
So the security team will insist on not learning anything about the environment at their new job (separation of duties!) but will want to install footguns on every server, and generate reams of automated scanner output that is 98% useless. Budgets get eaten up because we have to buy products from the magic quadrant, because they need to be easy enough for an under qualified person to use (I've heard this). Sometimes it feels like never-ending stream of XY problems and Chesterton's fences, but I guess that's just another day in IT.
The CIO and CISO don't understand that certifications only tell you someone is minimally qualified (at best). They are afraid of what they don't know (which is everything) and looking for something to conform to, some external authority on which to base their cargo cult. But they don't want to learn anything more complicated than a buzzword, so their first and last interview question for a security candidate is "what is the CIA triad?"
The old timers don't seem particularly anxious about security (because they understand where and how the rubber meets the road), which is misinterpreted as complacency.
So the security team will insist on not learning anything about the environment at their new job (separation of duties!) but will want to install footguns on every server, and generate reams of automated scanner output that is 98% useless. Budgets get eaten up because we have to buy products from the magic quadrant, because they need to be easy enough for an under qualified person to use (I've heard this). Sometimes it feels like never-ending stream of XY problems and Chesterton's fences, but I guess that's just another day in IT.
Can confirm. This just happened to my team at work as well. Had to urgently update to "fix" a vulnerability in the linux kernel that had something to do with bluetooth... on a virtual machine running on a rack mounted server in our own datacenter.
I swear, a lot of the security people are some of the dumbest people in the whole building. I even had to explain to one of them why I can't just skip the forced password change needed after I had to reset their password and sent them the new one. I had to explain to one of the security guys that I must not have knowledge of his password, so he needs to immediately change it. Let that sink in...
I swear, a lot of the security people are some of the dumbest people in the whole building. I even had to explain to one of them why I can't just skip the forced password change needed after I had to reset their password and sent them the new one. I had to explain to one of the security guys that I must not have knowledge of his password, so he needs to immediately change it. Let that sink in...
I wish they would enrich their commit messages when they're "enriching" CVSS data.
https://github.com/cisagov/vulnrichment/commits/develop/
https://github.com/cisagov/vulnrichment/commits/develop/
You could add another vector to the score for 'out of the box deployment deviation'.
* If you need a rare CLI flag set, lower the score
* If you need a rare configuration property set, lower the score
* If you need undocumented behaviour set, lower the score
There should be a way to note that a configuration set is unlikely but possible.
* If you need a rare CLI flag set, lower the score
* If you need a rare configuration property set, lower the score
* If you need undocumented behaviour set, lower the score
There should be a way to note that a configuration set is unlikely but possible.
I hate security theater too, but seriously?
Reminds me of people who want to get away from sizing tickets in story points and instead use t-shirt sizes or some other more-abstract measure to avoid confusing the size with the hours/days to implement.
But we all do the translation implicitly anyway.
You use a scale of 1-4 (okay sure you use ordinal words, but it might as well be numeric for all the difference it makes), and get upset that others use a scale from 0-10 when you boycott their scoring system. And when you rightly complain that they scored incorrectly and they fix it you’re still upset because they put a number to it instead of a word?
Simply map your score from your domain over to theirs and move on with your life: Low => 2.5 Medium => 5 High => 7.5 Critical => 10
Reminds me of people who want to get away from sizing tickets in story points and instead use t-shirt sizes or some other more-abstract measure to avoid confusing the size with the hours/days to implement.
But we all do the translation implicitly anyway.
You use a scale of 1-4 (okay sure you use ordinal words, but it might as well be numeric for all the difference it makes), and get upset that others use a scale from 0-10 when you boycott their scoring system. And when you rightly complain that they scored incorrectly and they fix it you’re still upset because they put a number to it instead of a word?
Simply map your score from your domain over to theirs and move on with your life: Low => 2.5 Medium => 5 High => 7.5 Critical => 10
> You use a scale of 1-4 (okay sure you use ordinal words, but it might as well be numeric for all the difference it makes), and get upset that others use a scale from 0-10 when you boycott their scoring system.
> Simply map your score from your domain over to theirs and move on with your life: Low => 2.5 Medium => 5 High => 7.5 Critical => 10
Mapping a simple 1-4 severity scale onto a 0-10 scale creates a misleading sense of precision. Curl's scale is just a broad categorization—"Low," "Medium," "High," and "Critical" represent general levels of severity, not detailed gradations. And it's a simple to understand scale:
"Low" => Probably doesn't even affect me, I'll give it a look whenever I have some time, or even ignore it. "Medium" => Could affect me, I'll check it out whenever I have a chance. "High" => I should check it out, and will probably have to update. "Critical" => Stop whatever I'm doing, and patch it.
When you assign values like 2.5 or 7.5, it implies distinctions that don’t exist in the original system, such as suggesting there's a meaningful difference between 2.4 and 2.6.
This kind of conversion introduces a false level of granularity, distorting the purpose of the original scale and potentially leading to misinterpretation. For instance, a "Low" severity issue might range from a minor inconvenience to something just short of "Medium," but assigning it a fixed score like 2.5 oversimplifies this range and misrepresents the data.
It also leads to lower trust in the score, since you might see a 2.5 value for something that has a "one in a billion" chance of affecting you, or it's a feature you don't even have enabled in your build, or abuses something specific. So what could be a 1, is represented as a 2.5.
Mapping a simple 1-4 severity scale onto a 0-10 scale creates a misleading sense of precision. Curl's scale is just a broad categorization—"Low," "Medium," "High," and "Critical" represent general levels of severity, not detailed gradations. And it's a simple to understand scale:
"Low" => Probably doesn't even affect me, I'll give it a look whenever I have some time, or even ignore it. "Medium" => Could affect me, I'll check it out whenever I have a chance. "High" => I should check it out, and will probably have to update. "Critical" => Stop whatever I'm doing, and patch it.
When you assign values like 2.5 or 7.5, it implies distinctions that don’t exist in the original system, such as suggesting there's a meaningful difference between 2.4 and 2.6.
This kind of conversion introduces a false level of granularity, distorting the purpose of the original scale and potentially leading to misinterpretation. For instance, a "Low" severity issue might range from a minor inconvenience to something just short of "Medium," but assigning it a fixed score like 2.5 oversimplifies this range and misrepresents the data.
It also leads to lower trust in the score, since you might see a 2.5 value for something that has a "one in a billion" chance of affecting you, or it's a feature you don't even have enabled in your build, or abuses something specific. So what could be a 1, is represented as a 2.5.
Same can be said to Linux Foundation. Instead of trying to improve the system some turn to boycotting, nothing improves.
Isn't CVSS 4.0 [0] supposed to at least fix some of these issues?
[0] https://www.first.org/cvss/v4-0/
[0] https://www.first.org/cvss/v4-0/
They seem to have gone for 'add a metric for everything.
'Provider Urgency (U): Amber'
That tells me squat.
'Provider Urgency (U): Amber'
That tells me squat.
No, I really think this is the way. Pick fixed CVSS scores for each of your own LOW/MED/HIGH levels. Anyone who pays attention will know what's up, anyone who doesn't pay attention wasn't seeing enough detail to be meaningfully misled either way.
Think about it like significant figures, where too much precision is actually more of a lie than including all possible detail.