Oct 20, 2026, 6:43 AM"Ignoring the slop" cannot be done and it doesn't help. These reports created with the help of AIs point out actual problems, and sometimes vulnerabilities. Ignoring real vulnerabilities because they were found by AI does not make users safe and secure. It makes them vulnerable. We don't want that. (I don't call this "slop" because it's typically accurate and correct, even if too wordy)
@bagder i have an ethical issue with using GenAI tools. However I agree with you that, once you're provided with actual useful reports it would be difficult to ignore them. Yet, wouldn't it be reasonable to ask people to submit them in a form that is more digestible (aka, not too wordy), so you can do your work properly and easily filter the good reports from the bad?
Oct 20, 2026, 6:48 AM@jenesuispasgoth yes, one can object to its use, but when we get a real vulnerability reported and proven, we cannot in good faith pretend it doesn't exist just because we think the tech involved in digging it up is questionable. That would be a disservice to our users.
@bagder I am not disputing that. I think one could even start processing these reports "unofficially," but require the originator to re-submit with a better format, in order to make them get used to providing info that can be more easily assessed and then processed (and triaged), if that makes sense.
Oct 20, 2026, 6:55 AM@jenesuispasgoth sure, that can be done. The challenge is just that under this heavy load, all that means even more work and time spent...
@bagder my hope is that it would be a surge of efforts but for a longer term solution (I know, I'm being naïve).
Oct 20, 2026, 7:03 AM@bagder To what extent does a "PoC or GTFO" policy help or hurt a vulnerability disclosure process in the face of GenAI-submitted reports? Does it cut through the wordiness enough? Does it filter out nonsense reports enough to save triage time? Do you think it scares away well-intended reporters?
Oct 20, 2026, 7:06 AM@stiiin generally, most people present decent PoCs these days already from the start, since the AIs might just as well do that when they create the report. In general it helps. The biggest problem with the AI reports is all the words. The walls of texts that sometimes makes it a bit hard to figure out what exactly the problem is.
@bagder Yes I get that AI can be highly emotive for some people and represents a lot of social change, but just closing your eyes and labelling it all ‘slop’ is a bit of a fear reaction I think
@bagder
For me as a sysadmin (unemployed, help) it is starting to give patch fatigue.
Even on desktops and the unpacked part of my homelab I have daily security patches that often require killing my whole graphical session, because i.e. the login/session manager used some library from security-updates.
Or the kernel was patched, restart machines.
I kind of don't miss sitting on security announce mailing lists, but without those I might miss the info if the patch is apply now or later.
@bagder reasonable middle ground could be limiting the number of PR they can create across GitHub to a number which seems reasonable in a way that person raising the PR would have proof read it. This way number of PR you get are high quality, human reviewed ones. Also there should be a mechanism of sort where per user how many PR were raised and how many of them got rejected and also the quality of PR could be easily accessible.
Oct 20, 2026, 10:18 AM@bagder Yes it's quite a different problem to what it was previously, right? A year (?) ago it was 'hallucinated' vulnerability spam where the claims didn't stack up. Now these things are finding real vulns it's a very different issue.
Oct 20, 2026, 10:19 AM@tomw absolutely. A much harder problem!
@bagder I really appreciate you being forthright about this difficult situation. Your continued openness about what you notice happening is valuable to learn from. Thank you.
@bagder Once a vulnerability is established, of course it makes sense to patch it. But that assumes at least one actual person (preferably the submitter) confirming that the vulnerability exists and is correctly understood. And even with that caveat, there's still the question of when using an LLM to find vulnerabilities is justified: https://merveilles.town/@lrhodes/117382606706574127