Not validating submissions seems like avenue for massive attack. Flood the whole system with endless false reports. Thus making it significantly less reliable.
Not validating submissions seems like avenue for massive attack. Flood the whole system with endless false reports. Thus making it significantly less reliable.
That is exactly why many big projects are migrating to becoming CNA, so that randos can’t get assigned unqualified CVEs which nobody has looked at or validated.
Apparently RedHat is a CNA of last resort, so it might be possible to get your project under Redhat’s scope and go through them without having to be a CNA yourself.
What are the requirements to become a CNA?
The OSSF (Open Source Security Foundation) has a nice guide on how to become a CNA [0]. It's pretty involved though.
[0] https://github.com/ossf/wg-vulnerability-disclosures/blob/ma...
This is what the Linux kernel is currently attempting since becoming a CNA. edit: "This" being to sabotage the CVE system via DoS, to be clear.
What do you mean? It isn't a DoS to assign every single bug fix a CVE! Every single bug is making someone vulnerable in some way.
That's nonsense. The goal is and always has been to undermine the CVE system because Greg does not believe in the system. The kernel is the only project that marks CVEs to fixes, it's the only project that considers every bug to be a "Security" bug, and it has a multi-decades long history of telling the security world to fuck off - all consistent with what I've said.
No one else has the process that the kernel has, despite plenty of people having software that's deployed in very similar ways.
There's zero question - this is ideologically motivated, not a genuine good-faith attempt to leverage the system.
Or maybe it's ideologically motivated that other groups only identify certain bugs as security bugs?
Make a case then. My case is that Greg has, for decades, said that he hates the CVE system and rejected it and that the kernel objectively labels CVEs based on fixes (not the standard at all, CVEs are for vulns), etc. I can point to so many objective pieces of evidence to support my claim.
You seem to have a vague, leading question. If you want to say something about "other groups" or ideologies, go ahead.
Malicious compliance is compliance.
I don't know what you're trying to say at all. But no, the kernel is objectively not compliant because they label fixes with CVEs and not vulnerabilities. But even if they were compliant... what would that have to do with anything? Feels like a non sequitur.
It's very hard to figure out what point you're trying to make.
Every bugfix implies a bug.
I'm going to graciously give you one last chance to actually say something of substance before I stop responding entirely.
Haha, I was reading your comment as praise for Greg until the end
> What do you mean?
No analysis is being done in the linux kernel to assess vulnerability.
> It isn't a DoS to assign every single bug fix a CVE!
On people who care about this, it is, not in the project itself though.
> Every single bug is making someone vulnerable in some way.
Not every bug is making someone vulnerable. (docs bugs, test bugs) behavioral changes, performance improvements, the list goes on.
It's been a problem for awhile. Daniel Stenberg has talked about it numerous times on his/curl's blog for the last 4 years. They became their own CNA to try and control it, they opened a hackerone with rewards, but now removed the rewards because it got flooded with AI generated slop daily.
https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-eve... https://daniel.haxx.se/blog/2024/01/16/curl-is-a-cna/ https://daniel.haxx.se/blog/2025/04/24/how-the-cna-thing-is-...
And this year, some of the reports suddenly got good and meaningful. https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/
So the agents started doing something useful after a period of filling mailing lists and bug bounties with slop. Sound good, but that's not entirely a good thing. The volume of good reports is a burden as well, and it's likely that long-lasting open source C/C++ projects have legitimate vulnerabilities unpatched. But we don't have any new maintainers, I think.
The real question is will [when will] these vulnerabilities get fixed faster than they can be found. LLMs are finding a lot of real bugs that have existed without being noticed for 20+ years. It is generally expected [hoped] that in a short time all those 20 year old bugs will be fixed and LLMs will settle down to just things introduced in the last month (or perhaps this pull request) and thus be manageable.
Won't an LLM, prompted for a CVE report, always hallucinate one even if it isn't there? Why would they "settle down"?
That's becoming less common. The issue is that, if training only contains examples of CVE reports, then asking for one will get you one, even if it's not grounded in reality. But if training consists of many negative cases with the response, "I can't find one," them that will become the default unless evidence pushes it towards a report. It's a classic class size problem. SOTA models seem to have this largely solved, though a determined person (just like a determined boss) can prompt one into giving a false answer just to satisfy the request.
Two different points.
First, is there any reason they have to? The LLM makers are aware of this problem and doing things to stop it. Maybe they will start saying "I can't find anything". Already they refuse to provide some exploits.
Second, most people are not prompting for a CVE, they are asking to review and find issues if any. Which sometimes finds a CVE, but in my experience it sometimes does say "looks good".
Hence future CVEs on a lot of projects will likely demand working exploit code for testing. This at least attempts to lock the issue down to something more tangible.
[dead]