私有漏洞报告的速率限制

一句话看懂：GitHub 为私有漏洞报告加入每日提交次数限制，防止低质量、自动化生成的安全报告淹没真正有价值的漏洞。这一改动直接影响开源维护者、安全研究者以及依赖私有披露流程的企业团队。

事件核心：发生了什么

根据 GitHub Changelog 于 2026 年 10 月 1 日发布的更新，GitHub 私有漏洞报告功能（Private Vulnerability Reporting）现在对每个账号的每日新报告数量实施速率限制，限制同时作用于单个仓库和整个 GitHub 平台。触发上限的报告者会看到提示，要求稍后再试。

限制只针对新建报告，已有安全公告下的评论不受影响。仓库管理员可以设置自定义的每日报告总量上限，也能将可信研究者加入白名单，使其不受限制。配置入口在仓库设置的 Advanced Security 下，点击“Private vulnerability reporting”旁的 Settings 即可。该功能适用于已启用私有漏洞报告的公开仓库，覆盖 GitHub Free、Pro、Team 和 Enterprise Cloud。

为什么重要

开源维护者近年收到的漏洞报告数量明显上升，其中不少由自动化脚本批量提交，质量和可复现性都很低。这类噪声会稀释真正需要优先处理的安全问题，也让维护者更难与认真做研究的人建立信任。GitHub 这次选择用速率限制而非全面审核来应对，本质上是在安全披露的开放性和可用性之间重新找平衡。对依赖开源组件的企业而言，漏洞报告渠道的可靠性直接关系到供应链安全响应速度，因此这一调整不只是维护者的体验问题，也影响下游厂商的风险管理流程。

对用户/开发者/创作者的影响

对开源维护者来说，最直接的变化是可以少花时间清理垃圾报告，同时通过白名单机制保留与长期合作的安全研究者之间的通畅渠道。自定义每日上限也让不同规模的仓库能按自身承受能力调整策略。对安全研究者而言，正常提交单个漏洞不会受限，但如果习惯一次性批量提交多个仓库的报告，就需要调整节奏，避免触发账号级别的限制。对企业安全团队来说，私有漏洞报告流程的可预期性提高，意味着灰盒测试、众测项目的提交策略可能需要重新设计。