开源维护者正在被低质量漏洞报告淹没，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 漏洞报告流程的体验就是一次失败提交。允许列表能缓解这一点，但前提是维护者愿意主动维护它------对忙碌的小项目来说，这又是一份额外工作。
另一处局限是自定义上限只管自己仓库。真正的批量提交往往跨仓库进行，因此账号级别的限制才是主力，仓库级别的数字更多是让管理员表达"我这里能承受多少"。
对维护者来说，这次更新不产生新的安全能力，只是把噪音挡在流程之外。但对整个开源托管生态而言，它是一个方向性的表态：当自动化内容开始污染协作工具的输入端口，平台的选择不是提高门槛，而是给门槛配上一份可配置的白名单。