[kuschku]

Right now, the vast majority of CVEs reported are bullshit filed by wannabe security researchers for resumé padding. Look at all the useless CVSS 9.8's filed against curl. With LLMs, even more bogus reports get filed every single day.

CVEs assigned to every linux commit are more valid than each and every one of those bogus CVEs. Each and every one of them is associated with an actual change in a security-critical project.

If you want the flood of useless CVEs to stop, you have to clean your own house first.

[Avamander]

Bad CVEs elsewhere aren't an excuse.

[kuschku]

It's not elsewhere, it's bad CVEs everywhere. Curl is just a particularly good example because they document it so well.

[Avamander]

There are many more good and useful CVEs. I'd also kindly request you to suggest a better system.

[kuschku]

Filing a CVE used to be a dialog between the researcher, developers, and third-party domain experts. Accepting every random LLM-generated report and granting it a 9.8 score is not useful in any way.

I have to patch hundreds of CVEs in a month, and only a handful are actually valid. The vast majority is "CVSS 9.8: regex complexity explosion in $library" which my project only uses during build. But I've got to patch it, because it's definitely absolutely critical.

While the standard library bug that causes SSL connections to fall back to TLS1.1 instead of TLS1.3 by default is considered WONTFIX and gets REJECTED for a CVE.

[Avamander]

That's obviously really unfortunate, but again, what's better out there?