I’m actually surprised there aren’t MORE bogus CVEs out there, based on my experience with bug bounty programs.
No need for a bug-bounty program. I receive regular emails to any public address on our website, warning of clickjacking and capture of passwords (there’s no passwords nor sensitive data on our website), not using the strictest of all SPF/DMARC, …, all from “honest security researchers” and “expecting a bounty no less than 150USD”.
Security theatre something something…
A state sponsored team decides to creates hundreds of bogus CVEs that get through. People stop trusting CVEs and it becomes a dirty word. Legitimate CVEs now start getting ignored and there is no good mechanism to surface those properly to teams that need to know. People's systems are now more attacker friendly. Governments and corporations too.
Or, some private company steps in and says they'll take on the burden of sifting through the bogus. But they are not incentivized in the same way... and might only pick and choose what they work on, or not work on, or ignore their own CVEs.
Decentralized multi-party peer review might be one way around this - ensuring that no single entity can function as gatekeeper. It's a lot of overhead, though, and there's way more time sensitivity than there is with academic peer review processes. And who adjudicates who is an independent subject matter expert on Postgres?
It's a tough problem, made tougher by the fact that it's a "dark forest" environment where any potential advantage to any party will inevitably be leveraged.
Some form of curation of reports seems like it would be an achievable (partial) solution. It seems like it would be less than perfect, but perhaps better than the status quo.
They are a quite good communication channel. You just have to read them, instead of counting the data packages.
They are the problem everywhere, and if we somehow "fix" CVEs so it works the way they think it works, they will keep being the problem in a hundred other contexts.
Maybe we should focus on some other place than "fixing" CVEs. But I have no idea how to fix IT charlatanism. But well, I have no idea how to "fix" CVEs either...
It's always good to supplement with things like whether exploit tooling for said CVE exists (proof that there's some actual weakness behind the CVE) - or use data feeds like EPSS which rely on actual verified exploits to create their exploit probability score.
Hire security people that understand CVEs and if they apply to your environment or not.
Unfortunately it's a complicated system and even with valid CVEs out there they don't always make sense for what your application does.
I work in code security and implementation of this software in 'secure' environments and we always have customers complain that scanners find CVEs in our software. Then we have to send links to documentation explaining what the CVE means and that very particular implementation details are involved that make the CVE dangerous that are not met by our application. Then the clients want to do the 'well the app found it, you fix it' crap.
Security theater industry somehow fares well still.