[raesene9]

For another opinion on this topic https://jericho.blog/2024/02/26/the-linux-cna-red-flags-sinc...

Having a large number of new, unscored, CVEs in the Linux kernel is going to make things... interesting. From their lists https://lore.kernel.org/linux-cve-announce/ these just have a CVE and not really enough detail for anyone to assign a score without a lot of additional analysis, which reduces their usefulness.

To an extent it could be suggested they're just exposing an existing flaw in the system (CVSS scores which may be taken to be scientifically applied, are actually just matters of opinion in many cases), but it will cause a lot of problems with automated tooling and compliance.

[the8472]

> Notably, SyzScope has classified 183 bugs out of 1,170 fuzzerexposed bugs as high-risk. KOOBE has managed to generate 6 new exploits for previously non-exploitable bugs.

While the rate is low it does show that some bugs were indeed exploitable without that being known to the kernel devs. If an attacker is willing to invest more time than the kernel devs combing through commits to find vulnerabilities in the some older stable kernel then a big unlabeled pile saying "there's probably a vulnerability in there, go update" is correct.

[aryca]

This way of thinking is how almost everyone approaches CVEs, but is also out of date now. There are millions of open source projects (tens of millions really). This attitude of treating security bugs as some sort of special snowflake isn't realistic

There are easily hundreds of thousands of security vulnerabilities fixed every year that get no IDs because the current process is rooted in security from 1999 (the number is probably way way higher, but you get the idea)

Rather than obsessing over individual vulnerability IDs, we should be building systems that treat this data as one of many inputs to determining risk

[raesene9]

Accurately determining risk relies on decent starting data, otherwise you run the risk of Garbage-in, Garbage-out. Whilst things like VEX and EPSS can help, they are based on the starting point that is CVE assignment and CVSS score.

I don't particularly think that CVE+CVSS has been the "right" way to do things ever (definitely not in the last 10 years) but my thoughts don't really matter whilst regulators and governments apply special significance to them, which they do.

Security bugs are special if a regulator can deem you in non-compliance if you have too many of them.

This is of course leaving the whole area of attackers who actively try to exploit them to one side :).

[Arch-TK]

It's possible to take a somewhat unopinionated approach to CVSS, the issue is that such CVSS scores exist in a vacuum, and vulnerabilities exist in environments. It's not possible to really apply a CVSS score to a vulnerability in a specific environment without understanding the vulnerability and more or less ignoring the CVSS score.

In summary, CVSS scores can be very objective, but in those cases they're also worthless.