Copilot app 安全扩展公开预览支持怎样的扫描结果处理

Copilot app 的安全扩展公开预览，重点不是替开发者“自动清空告警”，而是把已有 code scanning 告警和当前改动的安全审查放进同一个工作面。它可以按严重性浏览告警、搜索和筛选结果，查看受影响代码，再让 Copilot 解释或尝试修复；修复只写入本地工作副本，提交和推送仍由开发者决定。

官方公告地址：https://github.blog/changelog/2026-10-28-security-extension-for-the-github-copilot-app/

如果你的目标是处理已经产生的告警，先用告警列表定位和分流；如果目标是检查尚未提交的代码变化，再运行 /security-review。两条路径都需要人工判断，公开预览并不等于自动合并或自动发布。

这项公开预览到底处理哪两类结果

把安全扩展看成两个入口会更容易理解。第一类是仓库已经通过 code scanning 产生的开放告警，适合做排序、筛选、解释、修复和关闭决策。第二类是开发者当前工作副本中的改动，适合在发起 pull request 前运行一次安全审查。

已有告警怎样从列表走到可审阅的修改

已有告警的处理顺序可以压缩成四个判断。先在开放告警列表中按严重性、搜索词和筛选条件缩小范围；再打开某条告警查看详情与受影响代码；接着根据上下文选择 Explain 或 Fix；最后在本地工作副本中审阅修改，并决定是否提交。

1. 先做分流，不要直接批量修复

公开预览会展示开放告警，并支持按严重性排序以及搜索、筛选。这样做的价值是先确定处理顺序：高影响问题、已有负责人或已经有修复中的 pull request 的告警，通常应该先进入人工分流，而不是把所有结果一次交给模型。

2. 在详情页确认上下文

打开告警后可以查看告警详情与受影响代码；需要更完整背景时，还能打开 github.com 上的完整告警页面。若某条告警已经关联 pull request，也可以先确认是否有人正在处理，避免重复修改。

3. Explain 和 Fix 是不同的动作

Explain 适合先理解规则为何命中、风险落在哪里以及需要检查哪些上下文；Fix 则是在已有信息基础上请求 Copilot 生成修复。两者都应该视为辅助动作，不能代替对业务语义、边界输入和回归测试的判断。

最重要的边界是：扩展只会把修复写入本地工作副本，不会自动 commit 或 push。开发者需要检查 diff、运行项目自己的测试和安全流程，再决定是否提交。

4. 不处理的告警可以 dismiss，但组织策略可能要求审批

对于明确不计划修复的告警，可以执行 dismiss。如果组织启用了 delegated alert dismissal，关闭动作会发送给审批流程，而不是立即完成。这个差异会影响团队的记录方式：个人试验可以先记录理由，组织仓库则应把审批人和理由纳入既有治理流程。

当前改动怎样用 /security-review 补一次审查

如果代码还没有形成新的仓库告警，已有告警列表并不能代表当前工作副本没有新问题。公告给出的入口是对当前改动运行 /security-review，然后把新的发现和现有告警并排查看。

# 在 GitHub Copilot app 的当前会话中审查尚未提交的改动
/security-review

# 代码发生变化后重新发起审查，避免继续依赖旧结果
/security-review

这里的第二次运行不是固定脚本，而是一个使用提醒：扩展会告诉你代码自上次审查后发生过变化，开发者应在重要修改后重新运行。若把代码审查当成一次性的“绿灯”，就会错过后续改动带来的新上下文。

Copilot 也可以在聊天中回答告警问题，使用的仍是安全扩展工具，并遵循应用中设置的工具权限。因此，团队在试用前应先明确哪些仓库、文件和操作允许交给 Copilot，而不是只关注按钮是否出现。

安装与使用前要核对哪些条件

官方公告给出了两种安装路径：在终端执行插件安装命令，或在 Copilot app 中点击 Customize，搜索 github-security 后点击安装。安装后扩展会自动启用，可从仓库会话中打开 Security canvas。

# 安装 GitHub 官方公告中给出的安全扩展
copilot plugin install github-security@awesome-copilot

不过，安装成功不等于每个仓库都能看到相同的结果。公开预览的使用条件至少包括以下几项：

• 该能力目前面向 github.com 和带数据驻留的 GitHub Enterprise Cloud；GitHub Enterprise Server 不在支持范围内。
• 查看已有告警需要仓库启用了 code scanning，并且当前账号有权查看这些告警。
• 私有仓库还需要 GitHub Code Security；Business 和 Enterprise 计划可能需要管理员先启用 GitHub Copilot app policy。
• 企业管理员可以通过 managed settings 控制开发者可以安装哪些插件。
• Explain、Fix 和 /security-review 使用当前选定的模型，并按 Copilot 的普通提示方式消耗 AI credits；浏览和 dismiss 不消耗 AI。

把它当成安全工作流的一层，而不是自动修复开关

这个扩展最适合放在“发现—理解—修改—审阅”之间。它减少了在告警页面和本地代码之间来回切换的成本，但并没有改变修复的责任边界：模型建议需要代码审阅，修复需要测试，提交和推送需要开发者或团队流程确认。

如果团队主要痛点是告警太多，可以先从严重性排序、搜索筛选和关联 pull request 入手，建立告警分流规则；如果痛点是 pull request 前缺少对当前改动的检查，则把 /security-review 放进开发者的提交前习惯。不要一开始就把它包装成全自动门禁，因为公开预览、平台支持和组织策略都可能限制实际覆盖面。

试用前的判断清单

• 仓库是否真的启用了 code scanning，账号是否能看到对应告警？
• 团队是否区分“解释告警”和“生成修复”，并要求审阅本地 diff？
• 是否有规则说明何时 dismiss、何时需要 delegated approval？
• 当前改动在审查后是否仍可能变化，是否安排了重新运行 /security-review？
• 企业策略是否允许安装该插件，目标部署是否属于受支持的平台？

相关问题

安全扩展会自动提交修复吗？

不会。公告明确说明 Fix 只修改本地工作副本，不会自动 commit 或 push。提交前仍应由开发者检查 diff 并运行项目测试。

已有告警和 /security-review 有什么区别？

已有告警来自仓库已经运行的 code scanning；/security-review 面向当前改动，适合在创建 pull request 前补充一次审查。

dismiss 是否一定立即生效？

不一定。如果组织启用了 delegated alert dismissal，dismiss 会进入审批流程，由组织规则决定后续状态。

GitHub Enterprise Server 能用这个公开预览吗？

官方公告当前列出的支持范围不包含 GitHub Enterprise Server，因此不能按 GitHub Enterprise Cloud 的条件直接推断 Enterprise Server 可用。