GitHub为私密漏洞报告加入表单与限流：复现材料需要更具体，格式完整仍要人工判断

前天 3阅读

2026年10月1日，GitHub为私密漏洞报告推出结构化表单与每日限流。默认表单要求摘要、详情、复现证明和影响四项，其中复现证明至少150字符；报告者可以披露使用了AI辅助。适用范围是已开启私密漏洞报告的公开仓库，覆盖Free、Pro、Team和Enterprise Cloud。

管理员可以定制表单、设置仓库每日总量限制并添加可信报告者名单。每日限流针对新报告，不影响已有公告的评论。自定义表单也约束REST API提交；默认表单则不对API强制实施，现有集成不会因此被一律要求改写。

让信息更整齐，也要让人容易说“不知道”

以下为本文的维护建议。一个好表单应帮助报告者提供可核查材料，而不是诱导他们填满所有空格。环境版本、实际观察到的行为和复现前提通常比夸大的严重程度更有用。对于尚未确认的影响，允许写明未知，可以避免推测被包装成确定结论。

字符数门槛只能要求最基本的描述长度，不能证明材料有效。维护者仍应检查步骤是否足以重现、观察是否来自目标版本，以及结论有没有跨越证据。AI可以帮助整理语言，但报告由谁生成，并不能单独决定它是真的还是假的。

AI模型生成的概念示意图，表现结构化报告与有节制的接收入口，并非漏洞利用画面或真实平台截图。

收到一份报告以后，先确认材料已经进入处理流程，再安排核验，有助于减少双方误解。“已收到”只描述沟通状态；“已确认”则需要测试与分析证据。若自动回信把二者写成同一句话，后续统计也可能把尚未验证的报告算作已发现问题。

团队可以在现有流程中保留几种清楚的状态：等待必要信息、正在验证、已确认并安排处理，以及证据不支持当前结论。每次请求补充材料时，指出缺少哪一个具体条件，让报告者有机会用事实推进讨论，而不是反复提交更长的文字。

限制提交数量能够改变报告进入的速度，却不会自动决定哪一份应该先处理。维护者仍需要依据受影响范围、可复现程度和项目使用情况安排优先级。可信名单也更适合由明确的协作关系支撑，避免把一次有帮助的提交当成永久无需复核的理由。

对于已有自动提交工具的团队，值得先检查表单改动是否影响API路径。可以用无敏感内容的测试报告验证必填项、错误提示和最终描述，确认网页与集成两边的行为都符合预期。表单无效时会回到默认形式，也应在维护过程中被发现，而不是等报告者抱怨后才排查。

此次更新的实用意义，是把更多澄清工作提前到提交时。最后能否降低维护负担，还要看字段是否真正服务于核验、报告是否及时交到负责人，以及处理过程能否让双方知道下一步需要什么。

依据GitHub于2026年10月1日发布的结构化表单说明与限流说明。本文于北京时间2026年10月2日核验，后续流程建议为原创分析。