GitHub Agentic Autofix 正式发布：把安全告警变成经过审核的修复

安全告警会告诉你有问题需要关注，但未必会告诉你如何修改应用而不引入新问题。对刚开始维护小型应用的人来说，这个落差足以让修复无从下手；对开发者来说，熟悉的告警则可能越积越多。

GitHub 于 2026 年 10 月 15 日宣布 Agentic Autofix 正式支持代码扫描告警。将告警分配给 Copilot 后，智能体会调查代码、提出修改、尝试验证并创建草稿拉取请求。真正有用的变化在于起点：你拿到的是可检查的修复提案，而不再是一片空白编辑器。GitHub 正式发布公告，2026 年 10 月 15 日

本指南带你从确认仓库符合条件开始，走到审核第一项修复；之后还会介绍如何处理相关告警、自定义扫描器、成本和失败的尝试。我们的建议是：把智能体当作补丁作者，而不是发布审批人。在修改进入应用之前，你仍须理解它做了什么。

开篇示意图将智能体提出的修复与人工决定是否合并区分开来。

从一个告警开始，不要一口气处理整个积压

第一次最好挑一个你能解释、测试和审核的小改动。拉取请求是将改动合入项目主分支的提案；标记为草稿意味着它尚未准备好。CodeQL 是 GitHub 的代码分析引擎，可生成有关潜在易受攻击代码的告警。

开始大规模清理之前，先按以下顺序操作：

1. 选择一个由你管理的仓库。 开始智能体会话之前，确认资格、访问授权和计费负责人。
2. 先确认 CodeQL 分析正常运行。 如果仓库已有正常工作的分析配置，保留原配置并检查最近一次成功运行。若要新建配置，请在仓库的 Settings > Advanced Security > Code Security 中找到 CodeQL analysis，选择 Set up > Default，检查配置后选择 Enable CodeQL。等待分析成功完成。GitHub 设置说明，核对于 2026 年 10 月 18 日
3. 通过适用策略启用 Agentic Autofix。 仓库开关无法覆盖组织或企业级禁用策略。
4. 在默认分支上选择一个现有告警。 打开 Security and quality > Code scanning，进入该告警，然后在 Assignees 下选择 Assign to Copilot。GitHub 告警处理步骤，核对于 2026 年 10 月 18 日
5. 检查草稿拉取请求和会话日志。 阅读差异，运行相关测试，并用报告问题的配置重新扫描。
6. 只有通过人工审核和必要检查后才合并。 随后确认更新后的默认分支完成分析后，告警状态符合预期。

界面操作可参考 GitHub 正式发布公告里的官方演示。请将其与自己的仓库一起对照，不要假定示意图与当前每个屏幕完全一致。

公开或私有仓库能否使用？

发布公告重点介绍了企业客户。GitHub 当前的访问文档范围更广：包括 GitHub.com 上的公开仓库，以及启用了 GitHub Code Security 或 GitHub Advanced Security 的组织所有仓库。无需 Copilot 许可证。GitHub 访问文档，核对于 2026 年 10 月 18 日

公开访问并不代表智能体会话免费。邀请贡献者试用之前，先把仓库资格和使用费用分开核实。

从最高层级开始逐级启用访问

对于由企业拥有的组织，企业所有者或安全经理必须先在 Policies > Advanced Security > Agentic Autofix 允许此功能。仅有这项许可并不会自动启用它。随后，组织所有者或安全经理还要在 Settings > Advanced Security > Global settings 中启用；符合条件的仓库会继承启用状态。只有在更高层级策略允许时，仓库管理员才能选择退出或重新启用。独立组织不需要企业这一步；符合条件的个人公开仓库可直接使用仓库设置。预览版用户必须重新启用一次。GitHub 策略步骤，核对于 2026 年 10 月 18 日

访问示意图：许可、启用和仓库选择是彼此独立的决定。来源：GitHub 访问文档，核对于 2026 年 10 月 18 日。

在整个组织推广之前，列出应该保持退出状态的仓库，并确定谁负责审核生成的补丁。合理的试点团队由一位仓库维护者和一位安全审核者组成。记录告警、预期行为、审核者和预算负责人，避免无人跟进的草稿变成其他人无法解释的责任。

确认 CodeQL 确实分析了这些代码

默认设置要求启用 GitHub Actions，且仓库为公开可见或已启用 Code Security。不要只看开关是否打开，还要检查选中的语言和查询套件。如果现有高级配置运行正常，就不要轻率切换：默认设置会覆盖现有配置、禁用原工作流，并阻止通过 CodeQL analysis API 上传结果。GitHub 默认设置文档，核对于 2026 年 10 月 18 日

选择告警之前先查看最近一次分析结果。确认受影响的服务是否包含在内，以及构建或依赖项是否造成分析失败。设置显示已启用，不代表相关文件已成功分析。若基线不可靠，应先修复扫描配置，再请智能体处理其中的发现。

第一次尝试时，选一个影响范围小、预期行为明确的问题，例如数据库查询或特定输出渲染路径。不要从大范围授权重构开始。如果没有相关告警，不要为了演示而故意在运行中的仓库里引入漏洞。

从分配告警到草稿拉取请求之间发生了什么？

GitHub 描述的智能体会探索相关文件、生成修复、重新运行 CodeQL，并在创建草稿拉取请求之前迭代。提案包含修复摘要和验证详情。这是 Agentic Autofix 工作流，并不会自动合入默认分支。GitHub 正式发布工作流，2026 年 10 月 15 日

分配告警后按以下顺序审核：

1. 重新阅读原始发现。 找出不可信输入、敏感操作和预期防护措施。记下告警标识及报告该问题的配置。
2. 阅读所有变更文件。 查找无关改动、被移除的检查、被禁用的测试、新依赖和行为变化。
3. 检查会话证据。 区分已完成扫描、命令失败，以及无法验证的说明。你可以在会话中要求继续迭代，也可以在拉取请求评论里提及 Copilot。GitHub 会话指南，核对于 2026 年 10 月 18 日
4. 运行应用测试和相关扫描器。 在合适的开发环境中使用项目文档说明的测试命令。运行陌生代码之前，先检查设置脚本和工作流变更。
5. 请求人工批准。 若行为、扫描覆盖范围或责任归属仍未解决，就保持草稿状态。只有证据可供审核时才将其标记为准备就绪。

审核流程：智能体生成的草稿是中间产物，不是应用安全的证明。来源：GitHub 公告和告警处理文档。

GitHub 拉取请求在 Files changed 中显示差异，在 Checks 中显示自动结果。两边都要检查：绿色总结无法解释修改后的权限检查是否仍然执行应用规则。GitHub 拉取请求概念

工作流一：修复小型数据库查询，同时保持原有含义

设想一个虚构的 Python 服务：它根据标签查找库存物品。现有实现通过字符串格式化把标签插入 SQL，代码扫描告警指出这种查询构造方式有风险。可靠的修复应将 SQL 语句和值分开传递，而不是试图逐个删除标点字符。

使用 Python sqlite3 接口时，一种安全一些的示意实现如下：

def find_item(connection, label):
    return connection.execute(
        "SELECT id, label FROM inventory WHERE label = ?",
        (label,),
    ).fetchone()

这个占位符会将值与 SQL 文本分开绑定，符合 Python 官方参数绑定指南，核对于 2026 年 10 月 18 日。这是虚构的修复模式，不是 Agentic Autofix 的实际输出，也不是已报告的试验。真实服务中的查询、架构和授权规则仍需单独审核。

在这个例子中，测试应涵盖普通标签、带撇号的标签（如 Maker's Kit）以及不存在的标签。确认函数仍按预期返回一条记录或 None。然后测试调用该函数的端点现有访问规则；参数化查询并不能决定谁有权读取库存。

一种有用的审核意见是：“保持查找行为不变，将标签作为数据绑定，并添加覆盖撇号和不存在物品的回归测试。”这描述了契约，而不只是叫智能体让告警消失。接受之前，要用实际补丁重新扫描。

工作流二：归组处理相关告警，而非随意拼批次

假设某个虚构 Web 服务有三个告警，都与同一个响应渲染辅助函数有关。可以将它们放在一起审核，判断是否适合做一次共享修复。GitHub 允许从告警列表或安全活动中选择最多 25 个积压告警；一次分配会创建一个会话和一个拉取请求。GitHub 批量分配说明，核对于 2026 年 10 月 18 日

这个上限只是容量限制，不是建议批次。由同一负责人处理的三个相关发现，可能比横跨身份验证、文件处理和数据库访问的二十个无关发现更容易审核。分配之前，列出每个受影响的端点及其必须保留的常规行为。

在此示意工作流中，要审核共享辅助函数并测试每个调用方。如果修复更改了输出转义方式，就检查预期输出上下文，不要只因某个示例现在看起来正确就批准。若不同发现需要不同审核者或发布时间，应拆开处理。不要让一个尚未解决的告警掩盖其余修复到底有哪些证据。

工作流三：自定义扫描器必须单独确认

Agentic Autofix 仅处理默认分支上的积压告警。只出现在拉取请求或其他分支上的告警，不在此分配工作流的范围内。如果新拉取请求引入了发现，应直接在该分支上修复，而不是先合并有漏洞的代码，仅仅为了让它变成可分配告警。GitHub 范围说明，2026 年 10 月 15 日

还有一个边界：GitHub 表示，对于自定义 CodeQL 查询、security-extended CodeQL 查询套件，或第三方代码扫描告警，智能体验证无法确认修复是否有效。内置验证会尽力重新运行代码扫描查询套件。GitHub 验证限制，核对于 2026 年 10 月 18 日

设想一个虚构组织有一条自定义查询，用于强制执行内部数据处理规则。即使智能体提出了看似合理的补丁，审核者仍必须运行该自定义分析并检查结果。记录查询版本、配置、被分析的提交版本和结果。默认查询套件成功运行，不能替代报告问题时使用的那条查询。

保持更强的扫描器启用。为了得到绿色状态而降低覆盖范围，改变的是测量方式，而不是应用的安全性。如果无法重现所需分析，就让提案继续等待验证，并明确指出能运行该分析的负责人。

没有 Copilot 许可证，也不代表没有账单

Agentic Autofix 会消耗 Code Security AI 积分和 GitHub Actions 分钟数。GitHub 计费文档明确说明，即使公开仓库不要求贡献者许可证，也会消耗 AI 积分。若付费账户享有适用额度，会先使用已包含的 AI 积分；后续使用量按量计费。没有包含积分的账户则从一开始就按量计费。GitHub AI 积分计费说明，核对于 2026 年 10 月 18 日

组织仓库的费用由付费组织或企业账户承担。大范围启用前，应先检查该账户的可用额度和 Code Security AI 积分预算。公告还要求配置 Copilot 计费方式；这和要求每位用户都持有 Copilot 许可证不是一回事。GitHub 正式发布计费要求，2026 年 10 月 15 日

试点时记录会话用量、Actions 用量、审核者投入的时间，以及补丁是否被接受。不要承诺每个修复告警都有固定价格：批处理、迭代和未成功的提案也需要审查成本。应将已接受修复的成本与现有流程比较，而不要把生成了拉取请求就算成完成修复。

经典 Copilot Autofix 与之不同：它提供一步式修改建议，而非智能体调查并创建草稿的工作流；它的建议不会消耗 AI 积分。条件允许时，如果没有启用 Agentic Autofix，它仍然是一个可选方案。GitHub 功能对比，核对于 2026 年 10 月 18 日

合并之前，回答以下七个问题

这份审核清单不仅关注漏洞是否移除，也关注原有行为是否保留：

• **根因：**补丁修复了不安全操作，还是只把告警压下去了？
• **范围：**无关重构、新依赖和配置更改是否有充分理由？
• **行为：**有效输入、无效输入、错误和权限行为是否都正常？
• **测试：**是否有能捕获原始问题的回归测试？
• **分析：**报告告警的扫描器是否使用所需配置分析了提案版本？
• **批准：**是否有负责人审核了差异和智能体留下的未决事项？
• **合并之后：**默认分支分析是否确认告警状态符合预期，且没有新发现？

将“无法验证”视为尚未完成，而不是批准。GitHub 说明，智能体可能在拉取请求中报告无法验证，或怀疑某项发现是误报。这两种说法都不能替代维护者自己的评估。GitHub 尽力验证行为说明，核对于 2026 年 10 月 18 日

按钮不见了或结果不对时怎么办？

为什么看得到告警，却不能分配？ 检查告警是否属于默认分支积压、仓库是否符合资格、功能是否已启用，以及你的权限。分配需要写入权限。如果设置被上级策略锁定，应询问相应管理员，不要反复切换仓库开关。GitHub 分配前提，核对于 2026 年 10 月 18 日

扫描干净就能证明应用安全了吗？ 不能。它只回答了该分析及其配置覆盖的问题。业务规则、授权、运行时行为和不受支持的发现仍须适当测试和审核。

失败后要不要一直重试会话？ 先检查日志和建议的差异。判断缺少的是分析配置、测试执行、项目上下文，还是修复方案本身。提供精确的更正，或先修好底层配置再试；没有新增信息就反复分配，不是修复策略。

可以接受疑似误报吗？ 应独立调查发现并记录理由。不要把关闭告警和修复漏洞混为一谈，也不要让智能体的信心决定风险例外。

总结：提出修复，才刚刚进入审核

Agentic Autofix 将有用工作提前了：调查、候选补丁和可用的验证结果会一起到来。实际收益是，从发现漏洞到审核具体修复之间的距离缩短了。第一次尝试应保持范围小，扫描器保持原样，并依据证据决定是否接受，而不是依据补丁由谁编写。

来源

一手资料核对于 2026 年 10 月 18 日。

全文链接指向 GitHub 的10 月 15 日正式发布公告、当前访问策略、Autofix 概念与限制、告警处理步骤、CodeQL 设置和计费文档。文档反映的是带日期的访问状态快照，并不保证每个账户设置都相同。三种工作流均为示例，并非实际操作结果。

**留存审核笔记的地方：**在 Telli.sh 中整理来源链接、告警引用、测试结果和决策。它可以整理笔记，但不会扫描仓库，也不会批准修复。创建 Telli.sh 账户。