Drowning in AI-generated bug reports? GitHub has a radical answer: Stop accounts from reporting them.
GitHub’s new limits on bug reports aren’t a solution to the AI bug-report flood. Anything but! They’re an admission that the traditional security-disclosure workflow, with human maintainers in the loop, simply doesn’t scale. The scarce resource is no longer discovering security holes; it’s informed human judgment.
Specifically, GitHub has introduced daily rate limits on new private vulnerability reports. The goal is to give open-source maintainers breathing space to reduce the burden of low-quality and automated security submissions without closing off private disclosure channels to legitimate researchers.
As GitHub said, and we all know, open-source maintainers are receiving an increasing number of reports that “bury the reports that matter.” These new restrictions respond to the flood of bulk and automated filings.
As Dan Lorenc, co-founder and CEO of security company Chainguard, recently said in a webinar, AI is “now finding vulnerabilities in the software they write and the software they use at a pace that is far exceeding defenders’ ability to patch and get updates and fix the vulnerabilities.”
He continued that it was always easier to find vulnerabilities than to fix them, but AI has “poured another giant jug of gasoline onto the fire before inventing a better fire extinguisher.”
While we’re waiting for a better fire extinguisher, GitHub now caps how many reports a single account can file in a day both against a particular repository and across GitHub more broadly. Reporters who reach the threshold are instructed to try again later.
What are those numbers? We don’t know. GitHub hasn’t published them. The only way to find out if you’ve hit the limit is to slam into it. An AI bot mass-generating slop reports won’t care. Serious security researchers using AI will doubtlessly be ticked off.
These restrictions, however, don’t extend to existing bug reports after they have been filed. Comments attached to existing private advisories remain available. This means maintainers and reporters can continue investigating a valid submission even if the reporter has reached the new-report limit.
Repository administrators can also impose a custom daily overall reporting limit for their repositories and create an allow list for trusted reporters. The allow-list option lets maintainers exempt researchers, internal security staff, or established bug-bounty participants from the limits.
The controls are available for public repositories that have Private Vulnerability Reporting enabled on GitHub Free, Pro, Team, and Enterprise Cloud. GitHub places the configuration under:
Settings → Advanced Security → Private vulnerability reporting.
Private Vulnerability Reporting enables researchers to privately disclose a security issue to a repository’s maintainers rather than opening a public issue or immediately publishing technical details. GitHub says the channel enables maintainers to assess and address a finding before public disclosure.
GitHub’s new measure addresses volume rather than validity. It doesn’t determine whether a report is technically sound, set service-level expectations for maintainer responses, or resolve disagreements between researchers and projects about severity or scope. Instead, it gives GitHub and individual repositories a way to cap incoming report creation while preserving ongoing communication on reports already in progress.
That same day, GitHub also announced another change to improve report quality. That’s structured forms for private vulnerability reports. Rather than relying entirely on one free-text field, maintainers can request information needed to assess a finding, including a reproducible proof of concept.
Together, the form and rate-limit changes suggest GitHub is trying to improve the signal-to-noise ratio at the intake stage: For maintainers, the practical choice will be how aggressively to set repository-specific caps and whom to trust with an exemption. A low threshold may reduce noise but could create friction for productive researchers working across several related flaws. An overly permissive setting may leave the project with much the same triage load that prompted the new controls.
AI may, however, eventually provide the answer. As Madelyn Olson, co-founder of Valkey, told me at ValkeyConf in Prague, “We’ve created automated adversarial testing that looks for bugs and automated code reviews that generate pull requests (PR). Now, when you open a PR, we fine-tune a bot that looks for specific issues that are common in Valkey and is quite helpful at finding actual bugs.”
So, AI may have caused this problem, but with some work, it can also fix the problem