GitHub AI Scan for PR 正式 GA：补上 CodeQL 的盲区，但刻意不让它拦合并

GitHub 在 10 月 15 日把 AI Scan for pull requests 推进了正式可用（GA）。这不是又一个"AI 赋能"的营销词：它真正解决的是一个老问题——CodeQL 覆盖不到的语言和框架，在 PR 里长期处于裸奔状态。现在，PHP、Shell 脚本、Terraform 配置、Dockerfile 这些文件，也能在合并前被扫一遍了。但 GitHub 在同一份公告里写下了一行值得玩味的限制：AI Scan 的发现是纯建议性质，它不能让检查失败，也不能通过 ruleset 拦住一次合并。一个能看病但不许开处方的"医生"——GitHub 为什么这样设计？以及，这次 GA 里真正会影响团队预算的，其实是藏在公告后半段的计费规则。

发生了什么：10 月 15 日 GA，不再要 Copilot 许可证

根据 GitHub 官方 changelog（发布时间 2026-10-15），AI Scan for pull requests 正式结束公开预览。它的定位从一开始就很清楚：作为 CodeQL 的补充，去发现那些"CodeQL 目前不支持的语言和框架"中的漏洞。GA 公告点名的覆盖范围包括 PHP、Shell/Bash、Terraform 配置（HCL）、Dockerfile、Java 的 JSP、C# 的 Blazor，"以及更多"。对很多团队来说，这份名单读起来像一份"祖传代码清单"：部署脚本、基础设施即代码、容器定义——恰恰是历史上最少被静态分析照顾、又最容易出安全问题的角落。

启用条件很直接：仓库开启了 code scanning，并且仓库的 AI Scan 设置处于启用状态，扫描就会在 PR 上自动运行。发现会和 CodeQL 的结果并排出现在 PR 的 Conversation 和 Files changed 标签页，每条 AI Scan 的发现都带有一个 "AI" 标识，方便和 CodeQL 告警区分。每条发现可以附带一段自然语言写成的安全风险解释，以及一个建议的自动修复（autofix）。

GA 公告里最出乎不少人意料的一句是："A GitHub Copilot license is not required."——不需要 Copilot 许可证。这句话之所以重要，是因为在公开预览阶段，文档写的要求是 GitHub Advanced Security 许可证加 Copilot 许可证。GA 把 Copilot 从门票清单里拿掉了。可用性现在按仓库归属和可见性划分：组织或个人账号拥有的公开仓库可以直接用；组织拥有的私有或内部仓库则需要 GitHub Code Security 或 GitHub Advanced Security。个人账号的私有仓库不在覆盖范围内。

它到底在扫什么：9 个检测类别

GitHub 官方文档把 AI Scan 的发现归纳为 9 个类别，每个类别都给了明确定义。这是理解这个工具"视力范围"的最好方式：

• 字符串注入（String injection）：不安全地拼接 SQL、HTML、shell、JSON 或 YAML，缺少或做错转义/消毒。典型的例子：

// 用户输入被直接拼进 SQL —— 字符串注入的经典形状
$id = $_GET['id'];
$rows = $pdo->query("SELECT * FROM users WHERE id = $id");

// 修法：参数化查询，值与语句分离
$stmt = $pdo->prepare('SELECT * FROM users WHERE id = ?');
$stmt->execute([$_GET['id']]);

• 弱加密（Weak cryptography）：弱算法、过短密钥、不安全的随机数、该加密没加密、弱口令哈希。
• 越权（Broken access control）：路径穿越、CSRF 缺口、用户可控的重定向。
• 敏感数据暴露（Sensitive data exposure）：密钥、token、密码或堆栈信息被存储、记录或传输时缺少足够保护。
• 安全配置错误（Security misconfiguration）：危险的默认配置，比如关掉安全控制、打开调试功能。
• 认证失败（Authentication failures）：缺 TLS 或校验、认证流程不安全、缺少限流。
• 数据完整性失败（Data integrity failures）：不安全的反序列化、敏感操作走 HTTP、原型污染、执行不可信内容。
• SSRF（Server-side request forgery）：服务端去抓攻击者可控的 URL、主机或协议。
• 供应链风险（Supply chain risks）：未 pin 的第三方 action、包或镜像，下载时不做完整性校验。

注意最后一条：未 pin 的第三方 action 本身就是 AI Scan 的一个检测类别。这和本文后面要讲的 GitHub Actions lockfile 形成了有趣的呼应——GitHub 一边在 PR 里提醒你"这个 action 没 pin"，一边推出了把 action 锁死的 lockfile 机制。两条产品线在同一个月往同一个方向使劲，不是巧合。

还有几个运行时的细节值得记住：AI Scan 不需要构建系统就能分析 PR 代码，必要时会用代码搜索从仓库里拉更多上下文；它用的是专门的提示词，会忽略你仓库里的 copilot-instructions.md 或 CLAUDE.md；扫描在 PR 创建时和每次新提交后触发，和 CodeQL 同一个节奏；而且它不再要求 CodeQL 的默认配置——即使 CodeQL 分析失败或还在等待，AI Scan 照样会跑。文档也诚实地写了一句：作为 AI 工具，它的发现可能包含误报，看到不对的可以用点赞/点踩反馈，帮助改进检测质量。

最关键的一行小字：纯建议，不能拦合并

回到开头那行限制。GitHub 在 GA 公告和文档里用不容误读的措辞写了三遍意思相同的话：AI Scan 的发现是建议性质（advisory），不会让 code scanning 检查失败，也不能通过 ruleset 来强制合并要求。用大白话说：它可以在 PR 里留言，但没有资格拍板。

为什么 GitHub 要刻意阉割自己新工具的"执法权"？文档里那句"发现可能包含误报"就是答案。CodeQL 是确定性静态分析，误报率可控，所以它的告警可以进 backlog、可以卡合并；AI Scan 是模型驱动的，GitHub 自己都不敢保证它的精确度，就不敢把它放进门禁。让一个会犯错的模型拥有否决权，是对开发者工作流的灾难——误拦一次合并，团队对整个安全工具链的信任就掉一截。GitHub 的选择是务实的：先让 AI 当"评审员"，不当"门卫"。

但这也带来一个现实的落差：很多团队听到"AI 扫 PR"第一反应是"终于可以自动拦住有漏洞的合并且省掉人工 review 了"。GA 的现实是，它拦不住任何东西。它的正确用法是 review 注释——人工 reviewer 在 Files changed 里看到带 "AI" 标识的留言，多一个视角；安全团队在安全总览里看趋势和修复率，评估这东西到底是在帮忙还是在制造噪音。指望它替代合并门禁的团队，现在就可以打消这个念头，至少在 GitHub 给出 ruleset 支持之前。

另外两个"不扫"的边界同样重要：来自 fork 的 PR 不扫，Dependabot 开的 PR 也不扫。前者对开源项目影响最大——外部贡献者基本都是从 fork 提 PR 的，这意味着开源仓库最需要被审的那部分代码，AI Scan 根本看不到。后者则是因为 Dependabot 的更新本身已经是可信流水线的一部分。以及，它只读 PR 的 diff，不做全仓库扫描：你去年合并进去的 PHP 漏洞，它不会主动去翻出来，除非有人改了那片代码。

真正的账：Code Security AI Credits

GA 公告里真正会让团队掏钱的部分，是计费。AI Scan 走的不是 Copilot 的座位费，而是一个独立的计量口径：Code Security AI Credits。在企业账单的 "AI usage" 板块下，它被归在 "Advanced Security" 产品项里展示，并且支持按 SKU 设置预算。

文档里把计费规则写得很细，值得逐条读：第一，如果账单账号已经通过 Copilot 权益附带了 AI credits，AI Scan 会先消耗这部分额度，用完之后才开始按量计量；第二，只有"符合条件的 PR 被实际扫描"时才消耗 credits，不扫不花钱；第三，如果设置了硬预算且额度用完，扫描会直接暂停、不再产出发现，直到管理员提高预算或进入新的计费周期。换句话说，预算花光的效果等同于把功能关掉——只不过是被动的。

这里藏着一个 GA 之后的新风险，文档里用加粗级别的语气提醒：组织层面的开关一旦打开，所有符合条件的、开了 code scanning 的仓库会立刻启用 AI Scan，仓库管理员可以事后逐个 opt-out，但在这之前，符合条件的 PR 已经开始消耗 Code Security AI Credits 了。先开枪后瞄准——管理员如果直接在组织层面一键全开，账单上的第一笔 AI Credits 消费可能来得比预期早。文档的建议是：开组织开关之前，先确认仓库的覆盖资格，盘点账单账号已有的 AI credits，再把按量预算配好。

所以"不需要 Copilot 许可证"这句话要完整理解：它确实降低了准入门槛——安全团队不用再为扫描去采购 Copilot 座位；但它没有让扫描变免费，只是把账记到了另一个本子上。对已经在付 Advanced Security 的团队，决策问题从"要不要买 Copilot"变成了"现有的 AI credits 额度够不够吃下这些扫描"。按量计费的扫描工具，天然 incentivize 你把它用在刀刃上：优先给风险最高的仓库开，而不是全组织无脑全开。

管理员视角：看板在同一周跟上了

GA 前后，GitHub 还补上了管理员侧的两块拼图。10 月 13 日的 changelog 宣布：security overview 里新增了 AI Scan 的指标看板（公开预览）。组织和企业管理员现在能看到 AI Scan 产生了多少发现、修复了多少、修复率是多少、哪些仓库产生的发现、选定周期内的趋势，以及开发者接受 autofix 建议的频率——最后一个数字最值得盯，因为它直接回答"这个扫描器是在帮忙还是在添乱"。同时，原来的 "CodeQL pull requests" 页面改名为 "Code scanning on pull requests"，下面分出 CodeQL 和 AI Scan 两个标签页，AI Scan 页还会拆出"带 autofix 建议"和"不带建议"的发现数。这个看板在 github.com（含 Enterprise Cloud）上面向 GitHub Code Security 或 Advanced Security 客户开放，Enterprise Server 这次不支持。

再往前一周（10 月 6 日），据多家媒体对 changelog 的引述，GitHub 已经把 AI Scan 的启用状态放进了 security overview 的覆盖视图：管理员能看到开了和没开的仓库各有多少，逐行看到每个仓库的实际生效状态，还能用 code-scanning-ai-scan-pr-scan:enabled / not-enabled 过滤，CSV 导出也多了一列。注意这个视图回答的是"开没开"，不是"扫得怎么样"——开着不等于扫过，更不等于修过。两块拼图合在一起，GitHub 给管理员的叙事是完整的：先回答覆盖率，再回答有效性。

给 vibe coder 的判断

如果你是用 AI 写代码的人，这次 GA 和你关系最直接的一点是：AI Scan 扫的，正是你最常产出的文件类型。vibe coding 的典型产出里，PHP 页面、部署用的 shell 脚本、Dockerfile、Terraform 配置占了不小比例——这些恰恰是 CodeQL 常年覆盖不到、AI Scan 这次补上的。以前这些文件进 PR 基本靠人工 review 肉眼检查，现在多了一个自动化的第二双眼睛，哪怕它偶尔误报。

但有三句话要记牢。第一，别把它当门禁：它现在没有资格拦合并，你的合并保护还得靠原来的 required checks；把它当成 review 助手，心态就对了。第二，fork 来的 PR 它不看——如果你维护开源项目，外部贡献的代码还是得靠人工和你原来的流程。第三，算账：如果你是组织管理员，开之前先看 AI credits 额度和预算，别让"一键全开"变成账单惊喜；如果你是个人公开仓库用户，直接开就是了，没有许可证门槛。

更长远的判断是：GitHub 把"AI 评审"和"合并门禁"拆开，是一个会被同行效仿的设计。模型的精确度还没到能执法的地步，但它的召回能力已经值得一个 reviewer 席位。建议和门禁的分离，短期看是功能阉割，长期看可能是 AI 安全工具最诚实的形态——先承认自己会犯错，再谈帮忙。

来源

• GitHub Changelog：AI Scan for pull requests generally available（2026-10-15）
• GitHub Docs：AI Scan for pull requests（含 9 个检测类别、可用性矩阵、计费规则）
• GitHub Changelog：Code scanning AI Scan metrics in security overview（2026-10-13）
• Pondero：GitHub's AI Scan for pull requests reaches GA without a Copilot license requirement（2026-10-16）