GitHub给私有漏洞报告加每日上限，低频噪音把维护者淹没了

A5站长网10月2日消息，GitHub在更新日志里宣布给私有漏洞报告加上每日速率限制。原因写在公告里：开源维护者收到的低质量与自动化提交越来越多，这些内容会把真正重要的报告压在下面。限制针对的是单个账号新建的报告，同时从仓库维度和全站维度做约束，对已有安全公告的评论不受影响，讨论流程照常。

具体阈值的处理方式和一般产品公告不太一样。GitHub没有给出一个统一的每日上限，而是把设置权交给仓库管理员：管理员可以自行设定本仓库的每日限额，同时把可信的报告者加进白名单，白名单里的账号不受限流。这种设计把噪声与真实报告之间的平衡点交给最了解自己项目的人，代价是每个仓库都得单独配置一次。

同日还有一项配套更新，GitHub上线了私有漏洞报告的结构化表单，让报告按预设字段提交，减少因为信息不全来回追问的次数。限流与结构化表单配合起来，指向的是同一个目标：把有限的处理能力留给有效信息。对报告者而言，填表的门槛略有上升，但一份字段完整、能复现的报告被忽略的概率也随之降低。

这项改动有两面。限流确实能挡住批量提交造成的噪音，但阈值设得过紧，也可能把真实研究者挡在门外，尤其是在漏洞奖励项目里，报告者往往就是一次性提交。GitHub把上限做成可配置、而不是一刀切，正是为了应对这种不确定性。对安全团队来说，这里有一个容易被忽略的操作细节：限流生效之后，如果只盯着收件箱的安静程度，很难判断是真的没人报，还是闸门开得太小。

放到更大的背景里，这和两周前另一条更新是同一个问题的两个侧面。9月下旬，GitHub给agentic autofix接上了Copilot Memory，用记忆能力让安全修复的经验在仓库里沉淀复用。一头是让机器帮忙修，一头是管住人工报告的入口。当AI把写报告和写代码的成本同时压低之后，开源项目的安全流程需要一套新的分流机制，而不只是更大的队列。

对运行开源项目的团队来说，比较稳妥的做法是先把限额设得保守一些，同时留一个备用的安全联系方式，避免限流生效后真正的紧急报告无处可投；白名单建议只加经过验证的报告者，并且在收紧阈值之前，回头复核一遍被延迟或拒绝的报告，确认没有被误伤。这套参数没有标准答案，只能跟着自己项目的报告密度调整。