> setting “fixed” (fake) scores on our CVE entries just in order to prevent CISA or anyone else to ruin them, but we have decided not to since that would be close to lying<p>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.<p>Think about it like significant figures, where too much precision is actually more of a lie than including all possible detail.
We must do <i>something</i>! This is <i>something</i>! Therefore we <i>must</i> do it!<p>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.<p>I’ve seen entire companies cripple themselves with this security theatre for days on end requiring usually some executive interjection to break the deadlock.<p>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.<p>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.<p>Bear in mind this was a brand new found vulnerability and there was no fix yet.<p>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 <i>anything</i>.<p><i>While the urgent fix for production was already committed and merged ready to be deployed.</i><p>It took great managerial pomp and fanfare to get that abolished.<p>I’d imagine there’s a great deal of pressure on OSS maintainers when these borderline CVEs get published.
I wish they would enrich their commit messages when they're "enriching" CVSS data.<p><a href="https://github.com/cisagov/vulnrichment/commits/develop/">https://github.com/cisagov/vulnrichment/commits/develop/</a>
You could add another vector to the score for 'out of the box deployment deviation'.<p>* If you need a rare CLI flag set, lower the score<p>* If you need a rare configuration property set, lower the score<p>* If you need undocumented behaviour set, lower the score<p>There should be a way to note that a configuration set is unlikely but possible.
I hate security theater too, but seriously?<p>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.<p>But we all do the translation implicitly anyway.<p>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?<p>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
Isn't CVSS 4.0 [0] supposed to at least fix some of these issues?<p>[0] <a href="https://www.first.org/cvss/v4-0/" rel="nofollow">https://www.first.org/cvss/v4-0/</a>