as i commented there: https://news.ycombinator.com/item?id=39054152
noone should ever be able to file a CVE without the product owner having a say in this.
filing a CVE should always include the party that is responsible for the vulnerability with proper checks and balances.
the current process allows accusing someone without the accused having any ability to defend themselves. it was created with the expectations that only security experts who know what they are doing will file CVEs. that expectation has not held.
this is pretty much why linus torvalds refused to announce when they fix security issues in the linux kernel.
That's a really stupid idea. CVEs track security vulnerabilities, not 'security vulnerabilities the product owner is prepared to admit to'.
Imagine if Cisco decided they were going to be the CNA for Cisco devices just weren't going to issue any CVEs for any vulnerabilities in any Cisco devices, regardless of whether they're exploited or not.
A possible resolution would be to have two kinds of CVE numbers: researchers can request and get assigned provisional CVE numbers that don't look like the current CVE numbers (e.g. pCVE-2021-3PF5), and the current CVE number format would be used for verified CVE numbers where the vendor(s) have confirmed them (e.g. CVE-2021-22204). Note that my example assumes that they still share the same identifier space: a conversion from "3PF5" to "22204" should be mechanical [1]. So researchers can still use pCVE numbers as needed, but proper CVE numbers would require vendor's cooperation. That sounds a reasonable trade-off for the security purpose.
[1] I've specifically used bijective vigesimal numbers with digits from Open Location Code in this example. So 1..20 = 2..X, 21..420 = 22..XX, 421..8420 = 222..XXX and so on. I've specifically picked OLC because it avoids many profanity possibilities, but an ideal scheme would also avoid all-number identifiers to clearly distinguish it from normal CVE numbers.
i do realize that many businesses would rather hide any security issues instead of acknowledging them. so a simple "no" or no response from them would not be enough.
but the current situation where we get a CVE for anything that is not proven to be safe (when giving that proof is very expensive to make) is also not helpful.
the linux kernel and curl becoming their own CVE authority is a hack to work around a broken process.
Linus Torvalds: "A bug is a bug."
As a kernel developer of ATM driver, I couldn't careless if there is a bug, much less some public authority (t)outing my driver as buggy. They'll get fixed, unit-tested, and real-world live-tested for the next release.
Every unfixed security issue is now no longer assigned a CVE until it's fixed. That's even worse.
I'm glad the LK finally has come to this conclusion, I dont care if it ends up exploding and using a lot of CVE's..
Good Work.
how about: CVF
Mature, you guys.
