Product1 publisher3 min readPublished
GitHub limits private vulnerability reports per day to spare maintainers' review time
GitHub now caps the private vulnerability reports one account can file each day, at thresholds it has not published. Admins can set their own limit and exempt trusted researchers.
The Product Desk · Product desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- GitHub said maintainers are getting a growing number of bulk and automated reports that "bury the reports that matter."
- Private Vulnerability Reporting lets researchers disclose a security issue to maintainers privately, so it can be assessed before details go public.
- The limit covers only new reports, so comments on private advisories already filed continue after a reporter reaches the cap.
- The controls apply to public repositories with private reporting enabled on GitHub Free, Pro, Team and Enterprise Cloud, under Settings > Advanced Security.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- constraint Because the limit counts reports without judging them, a sound finding from an unknown researcher competes with bot output for the same daily room.
- decision Picking a threshold and an exemption list commits a maintainer in advance to whose reports get read on a heavy day.
- exposure Researchers outside a project's allow-list find a threshold only by hitting it, so a high-volume reporter can lose a day on a valid submission without warning.
A researcher with a real finding submits a private report to a busy project and is told to try again later [5]. The report was turned away because the account had reached a daily count.
GitHub says the limits are there to give maintainers breathing room from low-quality and automated submissions, without closing private disclosure to legitimate researchers [1][9]. devops.com expects the limit to split its users. An AI bot mass-generating reports "won't care," it wrote. "Serious security researchers using AI will doubtlessly be ticked off." [15]
Limiting intake only makes sense if review is the scarce part. Dan Lorenc, co-founder and CEO of the security company Chainguard, said in a webinar that 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" [12]. Finding bugs was always easier than fixing them, he said, and AI has "poured another giant jug of gasoline onto the fire before inventing a better fire extinguisher" [13]. devops.com's conclusion: "The scarce resource is no longer discovering security holes; it's informed human judgment" [14].
GitHub's cap limits how many reports reach that judgment each day. Its other release that day targets the time each report takes. Structured forms replace a single free-text field with requests for what a maintainer needs to assess a finding, including a reproducible proof of concept [11].
I think the allow-list is the setting to fill in first, and the repository cap second. An exemption can cover outside researchers, internal security staff and established bug-bounty participants [3]. First-time reporters pay for that order, since anyone off the list competes for whatever daily room the cap leaves.
The first question for a project is where its valid reports have come from: regulars it could name in advance, or people filing for the first time. The second is whether its inbox is mostly noise or mostly real. With known regulars and a noisy inbox, the answer is to allow-list them and set a tight cap, and little real work is lost. Strangers sending the good reports into a noisy inbox is the hard case, because a tight cap there turns away the findings the project most needs. That project keeps the cap loose and lets the proof-of-concept request screen reports instead. Quiet inboxes need little beyond an allow-list, since GitHub's platform-wide limit already applies [2].
For any one project, the forcing question is how many of the last year's valid advisories came from people who could have been on the allow-list before they filed. If most did, a low cap costs the project little. If most did not, a low cap mainly filters strangers with real findings.
What to watch
- Whether GitHub publishes the per-repository and platform-wide thresholds that accounts currently discover only by hitting them.
- Whether researchers who hit the cap start filing through public issues instead, the outcome private reporting exists to avoid.