Today I read Josh Bressers' Why are vulnerabilities out of control in 2024? (via), which made me realize that I, along with other people, had been unintentionally propagating a misinterpretation of what a CVE was (for example when I talked about the Linux kernel giving CVEs to all bugfixes). To put it simply, a CVE is not what I'll call a (fully baked) security report. It's more or less in the name, as 'CVE' is short of 'Common Vulnerabilities and Exposures'. A CVE is a common identifier for a vulnerability that is believed to have a security impact, and that's it.

A CVE as such is thus an identifier and a description of the vulnerability. It does not intrinsically tell you what software and versions of the software the vulnerability is present in, or how severe or exploitable the vulnerability is in any specific environment, or the like, which is to say that it doesn't come with an analysis of its security impact. All of that is out of scope for a basic CVE. We think of all of these things as being part of a 'CVE' because people have traditionally 'enriched' the basic CVE information with these additional details; sometimes this has been done by the people reporting the vulnerability and sometimes it has been done by third parties.

(One reason that early CVEs were enriched by the reporters themselves was that in the beginning, people often didn't believe that certain bugs were security vulnerabilities unless you held their hand with demonstration exploits and so on. As general exploit technology has evolved, entire classes of bugs, such as use after free, are now considered likely exploitable and so are presumed to be security vulnerabilities even without demonstration exploits.)

As Why are vulnerabilities out of control in 2024? notes, the amount of work required to do this enrichment is steadily increasing because the number of CVEs is steadily increasing (even outside the Linux kernel situation). This work won't happen for free, and I mean that in a broad sense, since collectively there is only so much free time people have for (unpaid) vulnerability discovery and reporting. Our options are to (fully) fund vulnerability enrichment (which seems increasingly unlikely), live with basic CVE reporting, or to get fewer vulnerabilities reported by insisting that only enriched vulnerabilities can be reported in the first place.

(The current state of CVE reporting and assignment is biased toward getting vulnerabilities reported, which in my view is the correct choice.)

It's certainly convenient for system administrators and other people when we get fully baked, fully enriched security (vulnerability) reports instead of bare CVEs or bare vulnerabilities. But not only does no one owe that to us, we also can't have our cake and eat it too. If we insist on only receiving and acting on fully enriched security reports, we will leave some number of vulnerabilities active in our systems (which may or may not be known ones, depending on whether people bother to report them and make them into CVEs).

(This elaborates a bit on some Fediverse posts of mine.)