CVE counts are such a good example of “what’s easy to measure becomes the metric”. The moment Linux became a CNA and started issuing its own CVEs at scale, it was inevitable that dashboards would start showing “Linux #1 in vulnerabilities” without realizing that what changed was the paperwork, not suddenly worse code. A mature process with maintainers who actually file CVEs for real bugs looks “less secure” than a project that quietly ships fixes and never bothers with the bureaucracy.
If Greg ends up documenting the tooling and workflow in detail, I hope people copy it rather than the vanity scoring. For anyone running Linux in production, the useful question is “how do I consume linux-cve-announce and map it to my kernels and threat model”, not “is the CVE counter going up”. Treat CVEs like a structured changelog feed, not a leaderboard.
Is there a good public resource to figure out which parts of the kernel are the worst offenders e.g. is it a DoS in a driver for some ancient 8 bit ISA card or a remote code execution via ICMP echo requests?
shameless self promotion: I just launched a website [1] that tracks CVEs per kernel version since 2.6.12, it makes use of the tools that Greg KH will probably talk about in his next blog posts.
The point of the CVE system is to alert downstream users of security bugs, and giving Linux their own CNA has resulted in a deluge of reports to end downstream users of bugs that are ultimately not security related and in that respect Greg et al have completely failed.
9 comments
[ 2.9 ms ] story [ 27.1 ms ] threadIf Greg ends up documenting the tooling and workflow in detail, I hope people copy it rather than the vanity scoring. For anyone running Linux in production, the useful question is “how do I consume linux-cve-announce and map it to my kernels and threat model”, not “is the CVE counter going up”. Treat CVEs like a structured changelog feed, not a leaderboard.
[1] https://www.kernelcve.com