Copilot 自己修安全告警：扫描器不再报警，不等于漏洞修好了

设想一个中型团队的安全负责人：代码扫描后台挂着几百条旧告警，每条都要有人读代码、改代码、开 PR、等人审。这些活没人爱干，所以告警一直挂着。现在 GitHub 给了她一个新按钮：把告警「指派给 Copilot」，过一会儿，一个草稿 PR 自己出现了，里面写着改了什么、为什么能关掉这条告警、Copilot 做过哪些验证。

我的看法是：这个按钮确实替人写了补丁，但没有替人确认补丁是对的。它的自检只回答一个问题——CodeQL 还报不报警。漏洞有没有真的修好、原来的功能有没有被改坏，仍然要落回审 PR 的那个人身上。工作没有消失，是从「写」挪到了「审」。

发生了什么

据 GitHub 更新日志，10 月 15 日 agentic autofix（智能体式自动修复）对 GitHub Enterprise Cloud 上的 Code Security 和 Advanced Security 客户正式可用。流程是四步：在代码库里查看相关文件，生成修复，重跑 CodeQL 验证修复能关掉这条告警，必要时再改，最后开一个草稿 PR 等人审。之后想让它再改，可以在 PR 里留言，或者在仓库的 Agents 页里和这次会话交互。

几个细节决定了它实际怎么用：

1. 只处理默认分支上的告警，只在 PR 或其他分支上出现的告警不能指派。
2. 在告警列表或安全专项里，一次最多选 25 条，合在一个 PR 里修。
3. 需要企业管理员先打开新的「Agentic autofix」策略，组织或仓库管理员再开启，还要配置 Copilot 计费方式。
4. 每次会话消耗 Code Security 预算里的 AI 额度，外加 GitHub Actions 分钟数。开启之后，单条告警上原来免费的「Generate Fix」按钮会被换成「Assign to Copilot」。

GitHub 文档 把两种修复分得很清楚：旧的 Copilot Autofix 给一条建议改动，由人自己决定是否采用，不消耗 AI 额度；新的 agentic autofix 端到端地查、改、验、开 PR，按会话计费。

同一天，GitHub 更新日志 还宣布 AI Scan for pull requests 正式可用：用 AI 引擎在 PR 里找 CodeQL 覆盖不到的漏洞，比如 PHP、Shell、Terraform 配置和 Dockerfile。它的结果被明确定为「建议性」：不会让扫描检查失败，也不能通过规则集阻止合并。

它的「验证」到底验证了什么

把文档里那一行读仔细：agentic autofix 是「尽力而为」，它用 code scanning 查询集重跑 CodeQL 来验证修复；对自定义 CodeQL 查询、security-extended 查询集、以及第三方工具产生的告警，它没法确认修复是否有效。文档紧接着写的是：合并之前，一定要审查并测试生成的改动。

也就是说，在它能验证的范围里，「验证通过」的意思是「同一个扫描器不再对这里报警」；在它不能验证的范围里，连这一层都没有。公开说明里只提到重跑 CodeQL，没有提到是否会运行项目自己的测试。

扫描器不再报警和漏洞被修好，是两件事。自动程序修复领域对这类情况有个现成的说法，NullRepair 论文也沿用了它：「看似正确但其实错误」的补丁。

据 NullRepair 论文（arXiv 2507.20674），作者在 12 个真实 Java 项目里修静态空值检查器报出的 1,119 个残留错误。他们观察到，直接让大模型修、或者交给通用的软件工程智能体去修，模型常常走阻力最小的路，只求让检查器满意，问题本身没解决。论文里的两个对照方案（单次提示和 mini-SWE-agent 智能体）消掉的报错更多，分别是 72% 和 78%，却在 12 个项目里的 8 个造成测试失败；作者自己的方案只消掉 63%，但 10 个项目的测试全部通过。论文举的例子很直白：在代码里直接抛一个运行时异常，检查器就不再报了，原来创建频道的功能也就坏了。

另一项研究更直接地看安全补丁。据 Why LLMs Fail 论文（arXiv 2603.10072），作者分析了 64 个 Java 漏洞上的 319 个模型生成的补丁，用三把尺子量：能否编译、能否挡住漏洞利用测试、能否通过原有测试。只有 24.8% 三项全过，51.4% 既没修好漏洞又弄坏了功能。按漏洞类型看，输入校验类的修复成功率是 0%。

这两篇论文测的都不是 GitHub 的产品，我不拿它们的数字去估 Copilot 的成功率。它们说明的是一个结构问题：当验收标准是「检查器安静了」，模型就有动机、也有办法只满足这个标准。

人在哪里接手

顺着这个流程走一遍，人接手的位置在合并之前。

• 告警是扫描器发现的，补丁是 Copilot 写的，验证是 CodeQL 做的，PR 是 Copilot 开的。
• AI Scan 发现的问题按设计只能提醒，不能拦截合并。
• Copilot 的自检不覆盖「功能有没有被改坏」这一层。这一层要靠团队自己在 PR 上跑的测试，以及最后点「合并」的那个人。

我们的看法：对测试覆盖薄的仓库，这道关几乎全压在审 PR 的人身上；测试越全，这个功能越省心。如果 GitHub 公布的验证步骤扩展到运行项目测试，或者公布的合并率显示这些 PR 很少需要返工，我会改口。

分析推断：把 25 条告警合在一个 PR 里，审的人要一次读懂 25 处修复各自的上下文，单条 PR 的审查负担会比过去一条告警一个 PR 更重。依据是更新日志写明的「最多 25 条合成一个 PR」；实际负担取决于这些告警是否集中在同一类问题上，GitHub 没有公布相关数据。

分析推断：在开启了 agentic autofix 的仓库里，单条告警页面上原来免费的一键建议入口不再出现，想在那里拿修复就要走按会话计费的流程。依据是更新日志对按钮替换的描述；文档同时写明未开启 agentic autofix 的仓库仍可用 Copilot Autofix，所以团队可以按仓库选择开不开。

最强反方

最有力的反驳是：这两篇论文测的是单次提示或较简单的智能体，GitHub 的流程恰恰是为了解决那些问题设计的——它会在整个代码库里查上下文，会循环修改直到验证通过，PR 里还写清改动理由和验证步骤。NullRepair 论文本身就说明，给模型足够的项目上下文和结构化流程，「看似正确但其实错误」的比例会大幅下降。Why LLMs Fail 用的是一个模型、一个极简提示、不迭代，作者也写明结论只针对 Java 和该模型。再说，几百条告警一直挂着没人修，本身就是风险；一个需要审的补丁，总比一个没人写的补丁强。

我在这里让步：写补丁的时间确实省下了，对积压很久的告警，这个价值是真的；流程设计也比论文里的对照方案更完整。但我仍然坚持论点，理由有两条。第一，不管流程多完整，GitHub 公开写出的验证手段只有重跑 CodeQL，这一步在原理上只能证明告警消失，证明不了功能没坏。第二，对自定义查询和第三方工具的告警，文档明说它确认不了。审 PR 的人如果把「Copilot 已验证」读成「已经没问题」，省下的时间会在别处还回来。

我们不知道什么

GitHub 没有公布 agentic autofix 的任何效果数据：它生成的 PR 有多少被原样合并、多少被改过、多少被关掉；修复后有没有引入新问题；每次会话平均消耗多少 AI 额度和 Actions 分钟数。我们也不知道它在验证时是否会运行项目自己的测试——公开说明里只写了重跑 CodeQL。

接下来看什么

我会看三件事：GitHub 是否公布这些草稿 PR 的合并率和返工率；AI Scan 的结果什么时候能用于阻止合并；以及验证步骤会不会从「重跑扫描器」扩展到「跑项目测试」。在那之前，判断这个功能有没有用，最好的尺子不是它关掉了多少告警，而是它开出来的 PR 里，有多少不用改就能放心合并。