开源维护者正在被低质量漏洞报告淹没GitHub 选择给这股洪流装一个阀门。GitHub 更新了私有漏洞报告Private vulnerability reporting功能为每名用户每天能提交的新报告数量加上上限。限制同时作用在两个层面单个仓库以及整个 GitHub 账号。官方给出的理由很直接——维护者收到的低质量和自动化漏洞报告越来越多真正重要的那些反而被埋在了下面。规则细节有几条值得注意。达到上限的报告者会看到提示被告知稍后再试限制只针对新报告已有安全公告下的评论不受影响仓库管理员可以为自己的仓库设置一个自定义的每日总体报告上限管理员还可以把可信报告者加入允许列表allow list进了名单的人永远不被限流。配置入口在仓库的 Settings选择 Advanced Security点击“Private vulnerability reporting”旁边的 Settings。该能力面向开启了私有漏洞报告的公开仓库覆盖 GitHub Free、GitHub Pro、GitHub Team 与 GitHub Enterprise Cloud 四个档位。私有漏洞报告本身是 GitHub 提供多年的机制让安全研究者不必把漏洞细节直接发到公开 issue 里而是走一条只有维护者可见的私密通道。它降低了“公开即泄露”的风险代价是维护者的收件箱成了唯一的过滤器——而这个过滤器近两年明显开始过载。背景是漏洞报告在生成式 AI 普及后出现的量级变化。curl 维护者 Daniel Stenberg 就曾多次公开抱怨大量由 AI 生成的漏洞报告内容空洞、结论不成立却照样占用志愿者逐条阅读的时间。当提交一份报告的成本趋近于零报告数量就会脱离质量单独增长这是所有依赖人工审核的开源项目共同面对的结构性难题。GitHub 这次的设计思路是把判断权交回维护者。允许列表是最有信息量的一条平台无法判断谁是真研究者那就让维护者自己定义什么是“可信”一键豁免。这条机制同时缓和了一个长期矛盾——公开的漏洞报告通道一旦被滥用最先流失的往往是长期贡献者的耐心。只限新报告、不限评论也是一个信号。要拦的是批量投递行为而不是讨论本身。对已经在处理某份安全公告的双方来说沟通不能因为限流而中断所以限制被精确地画在了“新提交”这条线上。代价是边界上的误伤。一个从未与项目打过交道、第一次提交报告的外部研究者如果当天已经在别的仓库提交过多次就可能被挡在门外只能看到“稍后再试”。对这类人而言第一次接触 GitHub 漏洞报告流程的体验就是一次失败提交。允许列表能缓解这一点但前提是维护者愿意主动维护它——对忙碌的小项目来说这又是一份额外工作。另一处局限是自定义上限只管自己仓库。真正的批量提交往往跨仓库进行因此账号级别的限制才是主力仓库级别的数字更多是让管理员表达“我这里能承受多少”。对维护者来说这次更新不产生新的安全能力只是把噪音挡在流程之外。但对整个开源托管生态而言它是一个方向性的表态当自动化内容开始污染协作工具的输入端口平台的选择不是提高门槛而是给门槛配上一份可配置的白名单。