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.
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.
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.
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.
Yes, because vendors love the idea that "the community" is doing the job of digesting and distilling security issues for them, and all they have to do is slap a graphical interface on that data to charge $100k/yr to customers. There is absolutely no reason the Linux CNA should dignify that concern.
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.
