The rise of artificial intelligence in cybersecurity has opened a Pandora's box of problems for software maintainers. While AI tools were once hailed as a democratizing force that would empower more developers to find and fix vulnerabilities, the reality has turned sour. Instead of isolated, high-quality reports, maintainers are now drowning in a sea of low-effort, automated submissions that waste hours of triage time and crowd out genuine issues. The problem has become so acute that even the creator of the Linux kernel, Linus Torvalds, has publicly lamented the state of affairs, calling the project's security mailing list "almost entirely unmanageable" due to the sheer volume of duplicate and irrelevant reports generated by AI tools.
This phenomenon is not limited to the Linux kernel. Across the open-source ecosystem, from small utility libraries to large infrastructure projects, maintainers report being overwhelmed. The core issue is that AI-driven vulnerability scanners have become extremely accessible. Anyone with a basic understanding of a programming language can now run automated tools that generate hundreds of hypothetical flaws, many of which are false positives or already known. As Torvalds noted in his release candidate commentary, "If you found a bug using AI tools, the chances are somebody else found it too." He urged researchers to add real value by also writing patches and demonstrating a deep understanding of the code, rather than just firing off random reports from a black box.
The sentiment is echoed by Jarom Brown, Senior Product Security Engineer at GitHub. In a recent public statement, Brown acknowledged that while the lower barrier to entry for security research is welcome in principle, his team is being inundated with submissions that lack any real security impact. These include reports without proof-of-concept code, theoretical attack scenarios that collapse under scrutiny, and findings that fall squarely into GitHub's published list of ineligible categories. Brown noted that bug bounty programs "across the industry are grappling with the same challenge, and some have shut down entirely." GitHub has stopped short of that extreme measure but has instituted new rules requiring submitters to validate AI-assisted findings before sending them in. From now on, any submission must include a working proof of concept that demonstrates exploitation potential and concrete security impact. Reports covering known ineligible categories will be closed as "Not Applicable," which could negatively affect the submitter's reputation score on platforms like HackerOne.
Brown also urged researchers to be concise. "Bloated, AI-padded reports slow down triage and waste everyone's time," he wrote. This is a crucial point: the junk reports are not just numerous, they are often long-winded, filled with boilerplate text generated by large language models that obfuscates the actual technical content. Triage teams must spend extra time parsing these documents to determine if there is any substance, further draining resources.
Beyond the impact on programs, the collateral damage extends to the entire security research ecosystem. Shubham Shah, co-founder of Assetnote and a highly respected security researcher, says organizations are now taking far longer to review legitimate reports and act on real flaws. This kills the feedback loop that keeps top researchers engaged. "The joy of reporting vulnerabilities to bug bounties is quickly dissipating," Shah warned. He noted that while bug bounty platforms like HackerOne and Bugcrowd are trying to fight the onslaught with AI-based triage and added controls, their efforts may not be enough. "Hopefully the platforms actually work this out, but until then, I can't see myself continuing to report high quality original research to certain programs where I have meaningfully contributed for a decade," he added. For experienced researchers, the near-term future may involve retreating to private vulnerability research and invite-only bounties, where noise is minimal and trust is high.
Open source projects bear the brunt of this deluge because they rely on volunteer maintainers whose time is severely limited. Unlike large organizations like Microsoft or Google, which have dedicated security teams to filter reports, a single maintainer of a popular project might have to handle dozens of submissions per week. The cURL project, led by Daniel Stenberg, is a case in point. Earlier this year, maintainers reached a breaking point and decided to stop accepting submissions through HackerOne entirely, eliminating monetary rewards for security reports. Stenberg hoped that dropping the bounty incentive would remove the motivation for submitting AI slop. "The best and our most valued security reporters still will tell us when they find security vulnerabilities," he believed at the time.
The project initially switched to accepting reports via GitHub Issues and email, but that experiment proved short-lived. After about a month, cURL returned to HackerOne because the alternative channels were less effective for receiving vulnerability reports. However, they stuck with the decision not to offer bounties. The results, as Stenberg described in April, were striking: the number of reports actually rose, but their quality improved dramatically. Even reports compiled with AI assistance were more thoroughly researched. The rate of confirmed vulnerabilities surpassed the pre-AI level of 2024. While that was a welcome development, Stenberg pointed out that the raised influx of "good" vulnerability reports presents a new problem. "This avalanche is going to make maintainer overload even worse. Some projects will have a hard time to handle this kind of backlog expansion without any added maintainers to help," he warned. In other words, even high-quality reports can be overwhelming if they arrive in large numbers.
HackerOne acknowledged the challenge in light of cURL's departure and return. Michiel Prins, Co-founder and Senior Director of Product Management at HackerOne, emphasized that as AI makes it easier to automate submissions, preserving signal quality becomes critical. "Our focus is helping programs manage that shift with workflows that filter noise early, surface credible reports, and keep vulnerability management sustainable, so open source communities can maintain the transparency and resilience they're known for," he said. HackerOne advised customers to refine the scope and submission guidelines to reduce noise, use AI-assisted triage tools, and pair automation with human oversight.
The Open Source Security Foundation's Vulnerability Disclosures Working Group is also stepping in. The group is actively seeking community feedback as it works to help open source maintainers tackle AI-generated junk reports. Their goals include compiling best practices, creating policy templates, and developing guidance to help maintainers spot and handle AI-assisted submissions. Such initiatives are desperately needed, as the scale of the problem is only growing. With each passing month, more AI-powered vulnerability research tools emerge, and the cost of running them continues to drop. The result is a classic tragedy of the commons: individual researchers benefit from submitting dozens of low-effort reports, but the cumulative burden threatens to collapse the very bug bounty systems that have fueled security improvements over the past decade.
The issue also raises questions about the role of AI in security research more broadly. While AI can be a powerful ally for automating the discovery of memory safety bugs, injection flaws, or configuration errors, it should not be used as a replacement for human understanding. The best security researchers combine automated scans with manual verification, deep code analysis, and context awareness. They understand that a report is only valuable if it can be reliably reproduced and fixed. As Torvalds put it, "Don't be the drive-by 'send a random report with no real understanding' kind of person." That advice is likely to become a guiding principle as the industry grapples with the unintended consequences of AI democratization.
In the long run, sustainable solutions will require a combination of technological, procedural, and social changes. On the technology side, AI can be used not just to generate reports but also to filter them—deduplicating, prioritizing, and even suggesting patches. Platforms like HackerOne and Bugcrowd are already exploring such approaches. On the procedural side, programs can tighten their submission guidelines, require proof of impact, and implement reputation systems that penalize spam submitters. On the social side, the security community must reinforce the value of quality over quantity. Researchers should be rewarded for thoroughness and for the contribution of patches, not just for finding a bug number. The transition will not be easy, but the alternative is a breakdown of trust and efficiency in the vulnerability disclosure ecosystem.
Meanwhile, maintainers are left to cope with the immediate flood. Many are considering drastic measures, such as limiting submissions to invite-only, raising the bar for acceptance, or even shutting down public bug bounty programs altogether. The cURL project's experience shows that removing monetary incentives can help shift the balance away from quantity and toward quality, but it also demonstrates that even high-quality reports can overwhelm a small team. The Open Source Security Foundation's working group is a step in the right direction, but actionable guidance and tooling cannot come soon enough. As one maintainer put it anonymously, "I spend more time rejecting AI slop than fixing actual bugs. That's not progress. That's regression."
Source: Help Net Security News