Copilot 能直接修扫描告警了：装安全扩展前先看 4 条边界

10 月 28 日 GitHub 在 changelog 上发布 Security extension for the GitHub Copilot app，状态是 public preview，条目挂着 application security、copilot、universe26 三个标签（来源 1、来源 2）。它做的事很具体：把仓库的 code scanning 告警搬进 Copilot app，发现、解释、修复、关闭都在一处完成。为什么现在值得看——预览期形态还会变，但”什么不支持、什么要额外付费、什么要等管理员”这版公告已经写死，先记边界比先记功能省事。

同一天的 changelog 上，它属于哪一波

把来源 1 与 changelog 索引 放在一起看，这条不是孤立发布。10 月 28 日是 GitHub Universe ’26 那批更新的集中投放日，索引上同日挂着 universe26 标签的还有 Copilot Fusion 的模型路由、GitHub Agentic Workflows、Agent Merge、Copilot code review 的 Max 与审批能力等多条（来源 2 的标题行逐条可见）。安全扩展是这批里唯一同时挂 application security 与 copilot 两个标签的条目，位置很清楚：把安全工具直接接到编码代理的界面上，而不是让开发者自己在告警页和编辑器之间开两个窗口。

这一点决定了它现在的形态：它是 Copilot app 的一个插件，不是一个独立产品。官方给出的安装方式是插件安装（copilot plugin install），装完自动启用，从仓库会话里打开 Security canvas 使用（来源 1）。形态在预览期仍可能调整，边界相对稳定，这也是本文把篇幅压在边界上的原因。

告警流被切成两段处理

按来源 1 的原文，扩展把能力切成两段。第一段是”仓库里已有的告警”：按严重度排序浏览全部开放的 code scanning 告警，用搜索和筛选收窄；打开单条能看到告警详情与受影响代码，需要更多上下文时再跳回 github.com 的完整告警页；可以多选告警让 Copilot 去 Explain 或 Fix；能看到告警关联的 pull request，判断是否已有人在处理；不打算修的可以 dismiss。第二段是”你正在写的新改动”：在当前改动上跑 /security-review，结果与既有告警并排显示；代码自上次检查后发生变化时，扩展会提醒你重跑。

还有一条容易被忽略：在对话里向 Copilot 询问告警时，它调用的是这个扩展的工具，和其它工具一样受你的 tool permission settings 约束（来源 1）。这是官方写明的机制，后果是推导的——如果你把代理的工具权限收得很紧，Explain/Fix 一样会被挡。

老流程与新流程的对照

来源 1 的原文措辞是”Until now, fixing a code scanning alert meant switching between the alert on github.com and the code in your editor”，以及”Copilot only makes fixes in your local working copy and doesn’t commit or push anything”。对照表里唯一没变的环节是提交那一行：这是我的判断，工具压缩的是”找告警、看代码、改代码”这段，”审、推、合”仍然在人手里。对把告警修复时限写进制度的团队，这意味着工具能改的是排班里的哪一段，得自己算。

装之前先看的 4 条边界

边界一：修复只到本地为止。 官方原文写明 Copilot 的修复只落在本地工作副本，不 commit、不 push（来源 1）。推导：安全修复的响应时间依旧取决于人什么时候把代码推出去，别把它当自动修复通道。

边界二：仓库与环境有门槛。 看、修、关闭既有告警要求仓库已启用 code scanning 且你有查看告警的权限；私有仓库还需要 GitHub Code Security；预览范围是 github.com 与带 data residency 的 GitHub Enterprise Cloud，GitHub Enterprise Server 不支持（来源 1）。推导：GHES 用户这版与你无关，内部规划里不必排期。

边界三：企业账号要管理员先动手。 任何 Copilot 计划都能装扩展、跑 /security-review；但 Copilot Business 与 Copilot Enterprise 需要管理员启用 GitHub Copilot app policy，开发者能装哪些插件由 enterprise managed settings 控制（来源 1）。同日索引上还有一条 Repository plugin defaults and enterprise plugin controls generally available（来源 2，此处仅按标题引用）。推导：企业里合理的顺序是先定插件白名单再推给开发，否则会卡在装插件这一步。

边界四：/security-review 只管当前改动。 官方写明它跑在 current changes 上，历史遗留告警仍要回列表逐条处理；代码自上次检查后变了会提醒重跑（来源 1）。另外组织启用 delegated alert dismissal 时，dismiss 会送去审批（来源 1）。推导：想借它批量清旧告警，会先在审批队列上排队。

哪些动作吃 AI 额度：一个可复算的口径

官方把动作分成两类（来源 1）：Explain、Fix、/security-review 使用你在 app 里选定的模型，与普通 prompt 一样消耗 AI credits；浏览与 dismiss 不消耗 AI。公告正文没有给单次消耗量，所以下面是按官方分类拆出的口径，不是官方数字：

# 官方给出的安装命令（来源 1）
copilot plugin install github-security@awesome-copilot

AI 额度口径（我按官方表述拆分，非官方数值）
计入 : Explain + Fix + /security-review      # 选定模型，与普通 prompt 同等计费
不计入: 浏览、搜索、筛选、打开详情、Dismiss   # 官方原文：don't use AI

按这个口径，”看看告警”不花钱，”决定怎么改”才花钱。反方视角是：把 Explain 当阅读辅助反复用，额度会默默累积。我的经验判断，不是官方说法——更省的用法是先自己读告警详情与受影响代码，只对拿不准的那几条动 Explain/Fix，/security-review 也集中在改动接近提 PR 时跑一次，而不是每存一次盘就跑。

和同日的安全发布放一起看

在来源 2 的索引上逐条数，10 月 28 日挂着 application security 标签的条目一共 5 条（计数口径：日期行为 Oct.28 且条目下挂该标签；这是我人工计数，不是官方统计），除本文这条外还有 Public monitoring for enterprises generally available、Push protection beyond predefined secret patterns、Code scanning for AI applications in public preview、AI Scan for repositories in public preview。再把 Agent Merge、Agentic Workflows 等条目放进来，同一天的图景是：扫描、密钥、依赖、监控、合并各有一个 AI 入口。

跨源对比能看出来的是，这个扩展补的是”告警处置”那一环的界面入口，而不是新的检测能力——它复用的是仓库已经开着的 code scanning 结果。这是我的推导：官方没说这条链路的先后依赖，但如果存量告警没被消化，后面那些新扫描能力只会把列表堆得更长；所以先把处置入口接进编码现场，是让前面几条发布产生价值的前提。

延伸阅读与一手出处

• 一手公告（本文主要依据）：Security extension for the GitHub Copilot app，2026-10-28，GitHub Changelog。
• 官方文档入口（changelog 正文指向它，安装细节以文档为准）：View and fix security alerts。
• 官方社区讨论帖（changelog 正文指向它）：GitHub Community discussion。
• 同日发布背景：Changelog 索引、application security 标签页、Universe ’26 recap。
• 产品页：GitHub Copilot app。