GitHub 于 2026年10月15日正式推出一项功能,由人工智能修复代码扫描发现的安全警报并重新扫描。符合支持条件的企业开发团队可将警报分配给人工智能,同时接收修复方案和验证记录以供审核。这种方式不仅提供修复建议,还会确认警报是否已解决。

1. 将修复建议与重新扫描结合

基于智能体的自动修复会让 Copilot 查看仓库中的相关文件,生成修复方案,再运行代码扫描工具 CodeQL,确认相应警报是否已解决。必要时会反复修改,随后创建草稿拉取请求,让团队在合入变更前进行审核。

该请求包含修复内容摘要、此次修复能够解决警报的原因,以及验证过程中执行的步骤。团队收到的不只是代码变更,还有修复依据和扫描记录。

修复请求准备好后,仍可在拉取请求中发表评论,或通过仓库的智能体选项卡向相应任务会话下达进一步修改指令。团队可以在同一工作流程中完善最初生成的修复方案。

2. 从警报页面和 API 分配任务

可以将仓库默认分支上的警报逐个分配给 Copilot。默认分支是仓库作为基准的代码分支。在仓库或安全活动的警报列表中,最多可选择 25 个警报,交由同一个拉取请求一并修复。

如需自动化,可使用更新代码扫描警报的 REST API。在表示分配对象的 assignees 字段中指定以下值。该值与原文一致,并非完整的请求正文。

["copilot-swe-agent[bot]"]

支持范围是默认分支上的代码扫描警报。仅在拉取请求或其他分支上发现的警报无法分配。因此,即使团队打算批量处理警报列表,也应先确认警报是否属于这一范围。

3. 需要企业策略与计费设置

该功能在 GitHub Enterprise Cloud 环境中提供,也包括指定数据存储区域的环境。

适用对象是在该环境中使用 GitHub Code Security 或 GitHub Advanced Security 的客户。需同时确认云端环境和安全产品的使用情况。

访问许可与实际启用是分开的。企业管理员须先在高级安全策略中允许新的自动修复策略。随后,组织或仓库管理员在相应范围的代码安全设置中启用该功能。还必须配置 Copilot 付款方式。

启用后,单个警报页面上原有的免费生成修复建议选项将被分配给 Copilot 的按钮取代。这并非在原有选项旁新增按钮,而是改变了该警报的修复启动方式。

4. 从重复操作转向用量与审核管理

开发团队可将相关文件查找、修改和重新扫描交给智能体,但会消耗代码安全预算中的人工智能额度和 GitHub Actions 运行时间。不应将其视为与免费生成修复建议相同的成本结构,而应将其看作以承担用量成本来减少审核准备工作的选择。

额度用量会在企业计费与许可证页面的人工智能用量区域中,以高级安全产品条目显示。代码安全额度还可设置产品级预算。管理员不仅能管理功能启用权限,也能确认支出管理入口。

官方未提供每条警报的额度消耗量、处理时间或修复成功率。因此,没有依据对节省成本或时间的效果作出量化判断。

重新扫描所确认的是相应警报是否已解决。结果仍是供审核的草稿,因此仍需由人来判断是否接受修复内容。

此次变化的核心是可以将修复与重新扫描一并委派,而评估是否采用时,应同时考虑支持范围、用量成本和人工审核。