AI代码扫描能批量开了，但它还不能替你挡住合并
内容提要
GitHub为AI代码扫描新增组织与仓库级REST API，支持批量启用，但仅限github.com预览，需高级安全与Copilot许可。AI扫描在PR时分析变更代码，补充CodeQL未覆盖语言，结果仅供参考，不能阻止合并，也不覆盖历史仓库。建议先试点、记录误报与修复率，再分批推广，并保留人工确认。
延伸解读
批量启用不等于自动拦截
文章强调，AI扫描的发现仅出现在拉取请求中，结果是建议性的，不能用于规则集强制阻止合并。这意味着即使组织通过API批量启用了扫描，也不代表漏洞会被自动挡住。团队需要明确区分“已启用”和“已形成门禁”，避免产生虚假的安全完成感。
与CodeQL互补而非替代
AI扫描主要覆盖CodeQL暂不支持或覆盖不足的语言，如PHP、Shell/Bash、Terraform的HCL、Dockerfile等，通过语义判断补充静态规则的盲区。但CodeQL提供高精度、可复现的确定性查询，两者应同时保留。安全团队可将AI发现作为新信号源，经人工确认后转化为规则，形成持续改进。
试点与度量是关键
文章建议先盘点CodeQL覆盖不足的语言，选择有成熟评审流程的仓库试点，记录误报、修复率、AI额度消耗和评审等待时间，至少观察两个迭代周期再分批扩大。管理报表应分开统计“扫描已运行”“发现被确认”“问题已修复”，避免启用率高而确认率、修复率为空。
权限与预览期风险
该API仅在github.com公开预览，GitHub Enterprise Server不支持，且需要GitHub Advanced Security和Copilot许可，消耗AI credits。授权令牌应遵循最小权限：读取组织状态需组织管理读权限，修改仓库状态需仓库管理写权限。脚本应固定版本头并处理403、404和422错误。
Q&A
GitHub 的 AI 代码扫描现在支持批量启用了吗？怎么操作？
是的，GitHub 在 9 月 10 日为 AI Scan 新增了组织和仓库两级 REST API。安全管理员可通过 /orgs/{org}/code-scanning/ai-scan 读取或更新组织级设置，仓库管理员则使用 /repos/{owner}/{repo}/code-scanning/ai-scan，请求体中的 pr_scan 取 enabled 或 disabled。这样团队可以按风险批量启用，不必逐个点 UI。
AI 代码扫描能阻止代码合并吗？
不能。AI 扫描的结果是建议性的，不能用于规则集强制阻止合并。它只在拉取请求中运行并分析变更代码，发现不会进入仓库安全页的历史积压，也不覆盖全仓历史。因此它不能代替合并门禁，仍需人工确认。
AI 代码扫描和 CodeQL 有什么区别？应该同时使用吗？
CodeQL 把代码转换为可查询数据库，用高精度查询寻找已定义的数据流和控制流问题，提供稳定低噪声的基线。AI 扫描则结合差异代码与搜索到的上下文，对字符串注入、弱加密、访问控制等类别做语义判断，主要覆盖 CodeQL 暂不支持或覆盖不足的语言，如 PHP、Shell/Bash、Terraform HCL、Dockerfile、JSP 和 Blazor。两者应同时保留：确定性查询擅长稳定复现已知模式，AI 更擅长理解跨文件语义和新框架写法。
AI 代码扫描目前有哪些使用限制和风险？
限制包括：仅在 github.com 公开预览，GitHub Enterprise Server 不支持；需要 GitHub Advanced Security 和 GitHub Copilot 许可，并消耗 AI credits；发现只出现在拉取请求，不进入仓库安全页的历史积压；结果是建议性的，不能强制阻止合并；模型可能误报，且不会读取 copilot-instructions.md 或 CLAUDE.md 等自定义指令；不覆盖全仓历史，不保证自动修复，也不能替代依赖扫描、密钥扫描、动态测试和渗透测试。API 预览期可能变化，脚本应固定版本头并处理 403、404 和 422。
如何在一个大型组织中试点和推广 AI 代码扫描？
建议先盘点 CodeQL 覆盖不到的语言与框架，选择试点仓库。例如平台团队管理 300 个仓库，可先通过组织 API 允许 AI Scan，再只给 20 个有成熟评审流程的仓库启用。两周后统计每类发现的确认率、修复率、每个有效问题消耗的额度和评审等待时间，再分批扩大。同时用细粒度令牌读取当前状态，修改动作放入受审计的管理流水线，记录误报、漏报线索、有效发现和 AI 额度，至少观察两个迭代周期。对高危类别增加人工确认或独立检查，不假设 AI 结果会自动挡住合并。
AI 代码扫描的治理能力体现在哪里？为什么说它让治理进入平台即代码？
治理能力体现在新增的组织和仓库两级 REST API 以及权限层级：组织级禁用时仓库不能自行打开，组织允许时单个仓库仍可退出。这种“上级设边界、下级做选择”的层级比散落在各仓库的手工配置更容易审计。安全管理者可以用脚本检查哪些仓库偏离组织策略，而不是靠表格追踪。因此核心不是扫描模型更强，而是治理能力终于能进入平台即代码。
