[saagarjha]

Some platforms do in fact do this. If you run the entire stack, more power to you. But the kernel is forked by a hundred different people and everyone has their own bug trackers for that, so having an identifier for a security bug is actually useful to unify those.

[gnfargbl]

I would have no problem at all with the kernel developers introducing the concept of a "universal bug identifier," and developing a system for cataloguing and managing those UBIDs. I would also have no issue with CVEs being replaced by a set of flags on those UBIDs, which people could take notice of or ignore as they saw fit.

I do have a problem with the kernel devs attempting to burn down the only system we presently have, however terrible it is, and with HN justifying the bonfire on the basis that CVEs were always broken anyway.

[tptacek]

"Universal bug identifier" is precisely the point of CVE. They're not "broken" anymore than a WONTFIX bug is.

[gnfargbl]

There's a good-faith community norm that CVEs are for bugs that the reporter believes are security-related. Sure, that norm is regularly violated, but community standards always are and it doesn't diminish their value.

[tptacek]

CVEs have been filed for e.g. memory corruption issues with no known exploit or even plausible path to exploit since time immemorial, or at least since time-since-CVE-was-invented. The idea that there is a burden of proof or certainty required to number something with a CVE is a commercial vendor invention.

It's easy to see why people want CVE to work that way! It implies that people numbering potential security issues are doing a fuckload of work for you. But that work isn't free, and CVE has other purposes in the research community. So, no, I don't think anybody is going to talk the kernel people down from this. They're right.

If you want a feed of "CVEs" that clear a plausibility bar, put that together yourself. A lot of people would love to consume it and sell it to their customers; you'll get a lot of uptake.

[gnfargbl]

It's an interesting idea, but I'm not sure the market is there for the "plausible CVE" replacement you mention. We already have EPSS and KEV, and we regularly see attempts to replace CVSS with something better -- Zoom did something recently, as did Vulncheck I think. They don't tend to get much traction.

[_tk_]

All the tooling that's been integrated everywhere is reliant on CVEs and CVSS. All vendors issue their vulns with CVEs, not ZoomVEs. Disruption is not likely unfortunately.

[worthless-trash]

More importantly, how do you even get the reporters full report, not all vendors will supply this information, a lot of CVE data is lacking especially in closed source vendors.

[worthless-trash]

Just to be clear, that the CVE assigner (CNA) believes are security related, not the person asking.

This is a CNA responsibility.