私有漏洞报告引入结构化表单

私有漏洞报告现在可以使用结构化表单，要求报告者提供你评估漏洞所需的细节，包括可复现的概念验证。单个自由文本框让提交低质量或 AI 生成的报告变得容易，也让你难以从中找到真正的信号。现在，默认情况下，报告者必须填写四个必填字段：摘要、详情、概念验证（至少 150 个字符）和影响。他们的回答会被合并到公告描述中，因此你仍像今天一样审查和编辑报告。你可以通过在仓库默认分支添加 .github/VULNERABILITY_REPORT.yml 文件来自定义表单。若要将表单应用到你所拥有的所有仓库，请将其添加到你的组织或账户的 .github 仓库。表单使用 issue form 语法，字段支持 min_length，因此你可以要求最低的细节程度。如果你的表单无效，将使用默认表单。你可以在 Settings > Advanced Security > Private vulnerability reporting 中要求报告者在提交前分配一个 CWE。组织和企业所有者可以通过策略强制执行此设置。如果你的仓库有安全策略，报告者在提交前会看到链接到你的 SECURITY.md 的横幅。报告者可以勾选“我在查找或撰写此报告时使用了 AI 协助”来披露 AI 使用情况。如果你添加了自定义表单，通过 REST API 提交的报告必须与之匹配。默认表单不对 API 强制执行，因此现有集成可以继续工作。当 API 提交不匹配时，错误会指向一个新端点，该端点返回你的仓库所强制执行的表单。此功能适用于启用了私有漏洞报告的公共仓库，在 GitHub Free、GitHub Pro、GitHub Team 和 GitHub Enterprise Cloud 上可用。了解有关私下报告安全漏洞的更多信息。

GitHub 把私有漏洞报告从单一自由文本框改为默认强制四个字段的结构化表单（摘要、详情、概念验证至少 150 字符、影响），并支持通过 .github/VULNERABILITY_REPORT.yml 自定义、组织级统一下发、CWE 必填开关以及报告者 AI 使用披露，以抑制低质量和 AI 生成报告。

• GitHub 把私有漏洞报告从单一自由文本框改为默认强制四个字段的结构化表单（摘要、详情、概念验证至少 150 字符、影响），并支持通过 .github/VULNERABILITY_REPORT.yml 自定义、组织级统一下发、CWE 必填开关以及报告者 AI 使用披露，以抑制低质量和 AI 生成报告。
• 原贴提到：Private vulnerability reports can now use a structured form that asks re
• 来源：github.blog

这是什么信号

GitHub 把私有漏洞报告从“一个自由文本框”改成默认强制的结构化表单：四个必填字段——摘要、详情、概念验证（至少 150 字符）、影响，报告者的回答会被合并进最终的安全公告描述，维护者的审核与编辑流程不变。

真正值得注意的不是表单本身，而是随之而来的一整套治理动作：组织级可通过 .github 仓库统一下发表单；可在 Settings 中要求报告者提交前分配 CWE；报告者需勾选是否使用了 AI 协助；通过 REST API 提交的报告必须匹配自定义表单，不匹配时错误会指向一个返回“本仓库所强制表单”的新端点。这表明平台在把“漏洞报告的输入质量”当成可以工程化约束的对象，而不是靠维护者事后筛。

为什么重要

• AI 让低质量报告的边际成本趋近于零。自由文本框对提交者几乎没有成本，对接收者却是纯负担。加字段、加最小长度、加 CWE，本质是把一部分成本转移回提交侧，让“随手丢一份 AI 生成文本”不再是无痛操作。
• 漏洞报告开始变成结构化数据。字段来自 issue form 语法，并直接并入公告描述，意味着报告可以被校验、被要求最小信息量、被组织策略统一约束。
• 治理可以一次配置、全组织生效。组织或企业所有者能通过策略强制 CWE 设置，这对有合规或安全审计要求的团队比逐仓库手配实用得多。
• AI 使用被显式披露。“我使用了 AI 协助”是一个勾选框，它不禁止 AI，但让分类和信任判断有了一个明确信号。

对谁有价值

• 开源维护者与安全响应者：最直接的受益方，报告少了无效往返，概念验证有了最低细节门槛。
• 企业安全与平台工程团队：组织级表单加策略下发，可以把漏洞报告入口标准化成内部流程的一部分。
• 安全工具与集成开发者：API 路径的兼容规则变了，需要知道默认表单不强制、但自定义表单会强制。
• 提交报告的安全研究者：要习惯填写结构化字段并披露 AI 使用。

可以怎么行动

1. 先在组织级 .github 仓库放一份 VULNERABILITY_REPORT.yml，让所有仓库默认继承，再对个别项目按需覆盖，避免逐仓库重复配置。
2. 用 min_length 控制字段深度。概念验证的 150 字符是默认门槛，如果你的项目需要复现命令或环境信息，可以把关键字段的下限调高。
3. 谨慎决定是否强开 CWE 必填。它提升分类质量，但也会增加提交摩擦，可能压低报告意愿；可以先用组织策略对高价值仓库试点。
4. 排查现有 API 提交通路。如果自建流程或第三方工具通过 REST API 创建报告，添加自定义表单后需要让它与表单字段匹配，并处理不匹配时的报错与新端点。
5. 补齐 SECURITY.md。有安全策略时，报告者提交前会看到指向它的横幅，这是低成本提升报告质量的抓手。
6. 内部同步“AI 使用披露”的含义。明确勾选后团队应如何调整分类与验证强度，别让这个字段只成为装饰。

风险与限制

• 表单是摩擦，摩擦不挑对象。它挡住低质量报告的同时，也可能挡住真实但表述能力有限的初报者，尤其是外部研究者的首次提交。
• API 路径不是自动受益者。默认表单不对 API 强制执行，只靠现有集成继续工作，所以结构化收益需要你自己在自定义表单上加码才能覆盖 API 场景。
• 配置错误会静默回落。表单无效时直接使用默认表单，如果没人注意到，你会以为策略生效了，实际并没有。
• 适用范围有限。该功能面向已启用私有漏洞报告的公共仓库，且限定在 GitHub Free、Pro、Team 和 Enterprise Cloud 的计划范围内，私有仓库场景不在本次覆盖里。

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

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

• Allison 原帖