How should CVE allocation fail?

Posted Jun 21, 2024 16:01 UTC (Fri) by madhatter (subscriber, #4665)
Parent article: How kernel CVE numbers are assigned

It seems to me that there are two basic ways to err in assigning CVEs: all security bugs will have a CVE (but some non-security bugs might also get a CVE), or all things with a CVE are security bugs (but some security bugs might not get a CVE). It further seems to me that some people (for example, those who make patching decisions based on the existence of CVEs) are implicitly using one scheme, while others (including the kernel CNA guys) are using the other. I'm not suggesting that either scheme is right, but all human processes are fallible, so deciding how you're going to fail is quite important.

Until there is consensus on this, I fear we will see people talking past each other, because they're missing the mismatch in underlying assumptions. I personally feel I can see a fair bit of that mismatch in some of the comment exchanges above: people are making excellent points at each other, but no high-level agreement is possible, because there is no low-level agreement.

How should CVE allocation fail?

Posted Jun 23, 2024 15:33 UTC (Sun) by farnz (subscriber, #17727) [Link]

From what I can gather, the CVE Project would prefer that if you err in assigning CVEs, you do so in the first manner - all security issues have CVE numbers, so that we can use the CVE number as shorthand for discussing a given security issue. If you want to filter out some security issues, that's what the CVSS vector is for - but that's metadata attached to CVEs, not an integral part.

And it's my belief that the next step forward for the kernel is going to be a way for the parties who care about security bugs (distros, security researchers etc) to contribute partial CVSS vectors for kernel CVEs, so that people who depend on not wasting time on "minor" (by their values) CVEs can filter based on partial CVSS vectors, and contribute back the bare minimum CVSS vector pieces that they've determined as part of "nope, not for us".