私有漏洞报告新增速率限制

开源维护者正在收到越来越多低质量和自动化的漏洞报告，这可能会埋没真正重要的报告。速率限制会限定单个账号一天内可以提交多少份新报告，既包括提交到你的仓库的报告，也包括在整个 GitHub 上的提交。这有助于保护你免受批量提交和自动化提交的干扰，同时合法研究者仍然可以联系到你。

私有漏洞报告现在对新报告按用户应用每日速率限制。达到限制的报告者会看到一条提示，要求他们稍后再试。限制仅适用于新报告。对现有公告的评论不受影响。仓库管理员可以为其仓库设置自定义的每日总报告上限。仓库管理员可以把可信报告者加入允许列表，让他们永远不会被速率限制。

要配置这些设置，请进入你的仓库设置，选择 Advanced Security，然后点击“Private vulnerability reporting”旁边的 Settings。该功能适用于在 GitHub Free、GitHub Pro、GitHub Team 和 GitHub Enterprise Cloud 上启用了私有漏洞报告的公开仓库。在我们的文档中了解更多关于配置私有漏洞报告的内容。

GitHub 在私有漏洞报告功能中加入每日按用户的新报告速率限制，并允许仓库管理员设置仓库级每日报告上限、维护可信报告者白名单，以减少批量与自动化提交对维护者的干扰。

• GitHub 在私有漏洞报告功能中加入每日按用户的新报告速率限制，并允许仓库管理员设置仓库级每日报告上限、维护可信报告者白名单，以减少批量与自动化提交对维护者的干扰。
• 原贴提到：Open source maintainers are receiving more low-quality and automated vul
• 来源：github.blog

这是什么信号

GitHub 对私有漏洞报告这一入口动了“配额”这把手：新报告按用户、按天设限，覆盖提交到单个仓库和整个 GitHub 的行为。这背后是一个已经持续一段时间的趋势——开源维护者被低质量、自动化生成的漏洞报告淹没，真正需要处理的那几份被压在下面。平台没有选择收紧或关闭入口，而是用限额加白名单的方式做流量治理，说明官方判断问题出在批量提交，而不是研究者本身。

为什么重要

漏洞报告本质上消耗的是维护者的注意力，而注意力是开源项目最稀缺的资源。当报告通道变成“谁都能灌”的管道，结果往往是维护者疲于应付、真报告被延迟处理，严重的甚至直接关闭对外报告渠道，反而让安全问题从公开流程转入私下沉默。速率限制加上仓库级的自定义总量控制，等于把“入口宽度”交回给维护者自己决定，这是把安全入口当成需要运营的资源来管理，而不是一个纯技术开关。

另一个值得注意的细节是白名单机制。它承认了“长期可信研究者”和“陌生提交者”不该被同一套规则对待，这在安全协作里是一个重要的区分。

对谁有价值

最直接的是热门公开仓库的维护者，尤其是长期被自动化报告骚扰的项目；其次是企业安全团队和在 GitHub 上做安全运营的人，他们可以把仓库级上限纳入内部的漏洞响应流程；对合规的安全研究者同样有价值，白名单意味着持续贡献能被识别，而不是被限流误伤。

可以怎么行动

仓库管理员可以进入仓库 Settings，选择 Advanced Security，在“Private vulnerability reporting”旁点击 Settings 完成配置：设定符合团队处理能力的每日报告总量上限，并把已经建立信任关系的报告者加入允许列表。同时建议把对外披露的口径写清楚（需要哪些信息、不接受什么形式的提交），让限额政策和研究者的预期对齐。

风险与限制

第一，限额只作用于新报告，已有公告下的评论不受影响，所以它治的是“入口洪水”，不是全部噪音。第二，白名单是需要维护的资产，名单过窄有可能挡住新的善意研究者，名单过宽又等于没设。第三，限额不等于质量筛选，达到上限后剩下的报告仍然需要分级和分流。第四，原文没有给出默认的具体额度，上限由仓库管理员自行决定，因此项目之间会出现差异，研究者也需要适应不同仓库的不同规则。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《私有漏洞报告新增速率限制》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖