GitHub 安全概览上线 AI Scan 面板。修复率等数据公开，安全团队免审代码。
- 新增 AI Scan 专属选项卡，展示总发现数与自动修复建议占比。
- 提供修复率、生成发现的仓库分布及趋势，量化 AI 安全工具效能。
- 目前处于公开预览阶段，支持 GitHub Enterprise Cloud 用户。
从黑盒扫描到量化运营的转变
以前安全团队看 CodeQL，只知道报了多少错。现在 AI Scan 引入了修复率和开发者应用自动修复建议的频率。这直接改变了安全工具的考核指标。以前是看发现了多少漏洞，现在是看解决了多少漏洞。对于产品经理和创业者来说，这释放了一个明确信号：AI 安全产品的核心价值不再是单纯的检出率，而是修复闭环率。如果你的 AI 安全工具只能报警不能自动给出修复建议，或者开发者不愿意采纳，那这个工具在 GitHub 的新体系下就是不及格的。
原文提到这些指标能帮助安全团队理解开发者响应。这其实解决了一个长期存在的痛点：安全工具和开发团队的对立。通过观察开发者应用自动修复建议的频率，安全团队可以量化开发者对 AI 修复代码的接受度。如果这个频率很低，说明 AI 给出的修复建议质量不行，或者不符合业务逻辑。这为安全团队优化 AI 提示词或调整工具配置提供了直接的数据支撑，而不是靠主观抱怨。通过选定报告期的趋势数据，管理者可以清晰看到 AI 工具引入后，整体代码安全质量的曲线是向上还是向下。这比单纯看某一次扫描的结果更有战略价值。
新旧面板的功能拆解与适用边界
原来的“CodeQL pull requests”页面现在改名为“Code scanning on pull requests”，并且把 CodeQL 和 AI Scan 分成了两个独立的选项卡。这种拆分非常务实。CodeQL 偏向传统的静态规则匹配，而 AI Scan 偏向语义理解和自动修复。对于拥有 GitHub Code Security 或 GitHub Advanced Security 的企业客户，你可以直接通过新面板对比两者的效能。在制定安全规范时，需要同时评估这两种工具的覆盖范围。CodeQL 擅长已知的模式匹配，AI Scan 擅长未知的逻辑漏洞，两者结合才是完整的安全网。
在落地时需要注意几个适用边界。首先，这个功能目前不支持 GitHub Enterprise Server。如果你的企业还在用本地部署的 GHES 版本，暂时看不到这些指标。其次，公开预览阶段的数据可能存在波动。不要立刻把修复率作为安全团队的唯一 KPI，先跑一个月看看基线数据。最后，AI Scan 选项卡会明确区分包含和不包含自动修复建议的发现数，这能帮你排查是 AI 没找到修复方案，还是开发者拒绝了方案。同时，生成发现的仓库分布指标能帮你快速定位哪些核心业务库是安全重灾区，从而优先分配安全资源。
如何开启与获取官方文档
只要你的组织在 github.com 或 GitHub Enterprise Cloud 上，并且订阅了 GitHub Code Security 或 GitHub Advanced Security，直接去安全概览里就能看到这个新面板。无需额外配置，数据会自动聚合。
了解更多关于 AI Scan for pull requests 的细节：
参与 AI Scan Community 讨论：
从这次更新可以看出，GitHub 正在把 AI 能力从辅助开发推向安全基建。AI Scan 已经脱离了单纯插件的定位，直接被纳入了核心的安全度量体系。对于投资人来说，AI 安全赛道的估值逻辑正在重塑。单纯卖大模型漏洞检测的故事已经讲不通了，能深度集成进 CI/CD 流程、并且能用修复率证明投资回报率的工具，才能拿到下一轮融资。安全团队的预算正在向能真正闭环的 AI 工具倾斜，不能提供修复建议的扫描器将面临被替换的风险。
看完想聊两句？
你们团队现在用 AI 辅助修 Bug 的采纳率大概是多少？是更信任 CodeQL 还是 AI Scan？
往期推荐
- ·150 亿美元 Tokenmaxxing 背后，AI 账单成了最贵虚荣指标
- ·
- ·
点击公众号头像 → 历史消息，可翻阅以上文章
