一句话看懂：GitHub 为私有漏洞报告引入结构化表单，默认要求提交者填写摘要、详情、可复现的 PoC 和影响四个必填字段，漏洞报告人还可以主动声明”我使用了 AI 辅助”。这是平台面对 AI 生成低质量安全报告泛滥的一次直接应对。
事件核心：发生了什么
根据 GitHub Changelog 2026 年 10 月 1 日的更新，启用私有漏洞报告（Private Vulnerability Reporting）的公开仓库，其报告入口从单一自由文本框改为结构化表单。默认四个必填字段为：摘要、详情、概念验证（至少 150 字符）、影响，报告者填写的内容会合并进 advisory 描述，维护者的审核与编辑流程保持不变。
仓库可通过在默认分支添加 .github/VULNERABILITY_REPORT.yml 自定义表单，组织或账号级 .github 仓库中的配置可覆盖名下全部仓库。表单沿用 issue form 语法，字段支持 min_length 强制最低详细程度，配置无效时回落到默认表单。管理员还能在 Settings > Advanced Security > Private vulnerability reporting 中要求提交者先指定 CWE，组织与企业所有者可通过策略强制执行。若仓库设有安全政策，提交前会展示指向 SECURITY.md 的横幅。API 方面，自定义表单会对 REST API 提交做校验，默认表单不强制，以保证既有集成不中断；不匹配时错误信息会指向一个可返回当前生效表单的新端点。该功能面向 GitHub Free、Pro、Team 和 Enterprise Cloud 上已启用私有漏洞报告的公开仓库。
为什么重要
GitHub 在更新说明中点明了动机：单一自由文本框让低质量或 AI 生成的报告更容易提交，也让维护者难以从中找出真正有价值的信号。这与当前安全披露生态的现实直接相关——大模型让批量生成看似合理、实则无法复现的漏洞描述成本极低，开源维护者本已有限的精力被进一步稀释。用结构化字段和最小长度约束提高提交门槛，本质上是把”筛选成本”从维护者一侧前移到报告者一侧。
同时，允许报告者勾选”我使用了 AI 辅助来发现或撰写此报告”，是一种务实的信息披露设计：不禁止 AI 参与，但要求来源透明。这为后续判断报告可信度提供了元数据，也可能成为其他漏洞平台（如 HackerOne、Bugcrowd）参考的产品方向。
对用户/开发者/创作者的影响
对开源维护者，这是直接的减负工具：可强制 CWE 分类、设定 PoC 最低长度，并引导报告者先读 SECURITY.md，减少来回沟通。对安全研究者，提交路径变长，但表单可自定义，团队可保留自己的工作流。对通过 API 或第三方平台集成 GitHub 漏洞报告的安全厂商，需要关注自定义表单带来的校验变化；依赖默认表单的现有集成不受影响，但若仓库启用了自定义表单，API 提交必须匹配其结构。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是看默认表单与 150 字符 PoC 门槛能否实际压低低质量报告比例，GitHub 是否公布相关数据；二是看 AI 使用声明字段的采纳率，以及它是否会影响报告的审核优先级；三是看其他漏洞披露平台是否跟进类似的结构化与 AI 披露机制。
