I'm curious how you'd account to factors like `npm audit` failing on probably most javascript repos out there on reasonably high CVSS settings due to including items like <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-3807" rel="nofollow">https://nvd.nist.gov/vuln/detail/CVE-2021-3807</a> ? And particularly, how to fix that, or Working As Intended?
Very great article.<p>At the moment IMHO the major issue comes from that people use only the Basic Score of the CVSS 3.1, issued by the NVD.<p>Indeed, if you also take the Temporal Score (with CTI feeds for example), and if you add the Environmental Score, then you can have very good results to help prioritizing the vulnerabilities on your assets and reflect the real threat.<p>I would also like, however, to see the CVSS4 with a "cost to patch" component: in OT environments, CISO like to use the SSVC because it’s the easiest way to say "wait" instead of "patch now". But since SSVC is not really recognized by all auditors, it generates conflicts.
Bringing a component in the CVSS to reflect the cost of remediation on very complex devices, where deploying a KB requires to stop a full factory, could help getting the same results (aka "don’t patch now and wait") but with a more respected scoring system.<p>From my perspective, that’s the only missing component for a good CVSS system :).
I built a CVSS2 calculator amongst other things; I came to the conclusion that they are trying to turn an art (how problematic an issue is) into a pure science and they keep realising they need ever more parameters. I’m glad they have tried but would rather trust a pen tester to help me rank issues within my organisation than attempt to use a one size fits all formula that doesn’t account for my specific situation perfectly.
"People misapply CVSS" is the crux of the post and all the criticisms (even the ones labeled as something else).<p>The other criticisms section starts with the "You're doing it wrong" commentary and then moves on to discuss two other groups saying what boils down to "You're doing it wrong and the metric is bad because it encourages you to do it wrong", which as a way of demonstrating diversity of opinion is entertaining at least.<p>CVSSv3.1 as a metric is not designed to have a uniform distribution of possible values from 0.1 -> 10.0 and it should not generally be a goal to develop a scoring system that does. It is designed solely to answer the questions of "which issue is more severe" when comparing different issues and to then help direct and prioritize fix work. It is not perfect at this but it is superior to other systems out there, especially when taking the pure severity of a given vulnerability in isolation.<p>I do get that people really do try to sell the idea that it's an infallible metric and that it means something substantially more than it does. It also gets confused often as "X is riskier because its score is higher", which is obviously wrong. If you have an authentication-related product, it's obviously more damaging to discover certain categories of information leakage than it may be to find cross-site scripting issues in general.<p>I think it is correct for a change in scope to have a much more outsized impact on the final score, something the author seems to sort of presume is wrong (referring to it as the "villain" at one point) without really explaining why they believe it is wrong. A scope change essentially means lateral movement to other systems rather than the compromise of a single piece of software.<p>Could a better metric be designed? Sure. I'd like to see some additional degrees of user interaction being accounted for, as just one example. The concept of vectors being Network, Adjacent, Local, or Physical could use some more fleshing out for the modern age, for another.<p>Does that mean alternative approaches are better? Not in my experience. All the alternatives I've experienced basically boil down to "we made our own system, don't publish the calculations, and lots more stuff is critical impact and risk" whenever you get reports. I've literally had third-party pentest teams try to sell me that an Info Exposure that was showing server IPs in a log was a High, because they used their own metric.<p>I'd argue that for what it is intended to do, CVSSv3.1 does a good enough job and that's why so many people have accepted it as a standard.