GitHub 刚刚把 AI 代码扫描的开关直接塞进了 REST API。2 个新端点，彻底告别在 UI 界面里逐个仓库点鼠标的低效操作。
对于管理着上百个微服务仓库的大厂团队，这不仅是少点几次鼠标的事。把安全扫描配置代码化，让你能够直接把它塞进 CI/CD 流水线，实现新仓库创建即自动开启 AI 防御，安全左移终于有了真正的自动化抓手。
核心看点
- 新增 /orgs/{org}/code-scanning/ai-scan 与 /repos/{owner}/{repo}/code-scanning/ai-scan 两个端点。
- 权限逻辑严格：仓库级设置无法覆盖组织级的禁用状态。
- 当前仅限 github.com 的 GitHub Advanced Security 客户，不支持 GitHub Enterprise Server。
▎API 端点与权限控制逻辑
这次 public preview 开放的核心是程序化控制能力。过去，安全团队要在几百个仓库里手动开启 AI Scan for pull request，不仅耗时，还容易漏配。现在，通过组织级 API，你可以一键控制整个组织内 pull request 的扫描运行状态。
注意这里的权限继承逻辑。组织级设置是全局开关，仓库级设置是局部开关。如果组织层面禁用了 AI Scan，你在仓库层面调用 API 开启是无效的。这种设计防止了底层项目绕过安全基线。
在实际落地时，你需要特别注意权限校验的失败场景。如果你的服务账号在组织级别没有被授予相应的 code scanning 权限，调用仓库级 API 会直接返回 403 或 404。此外，由于仓库设置不能覆盖组织级禁用，如果你的公司处于合规审计期，安全团队在组织层统一下发了禁用策略，业务线试图通过 API 强行开启扫描会直接失败。建议在批量调用前，先通过组织级 API 轮询一次全局状态，避免无效的并发请求浪费 API 速率限制。
▎配置对比与落地排查清单
这里没有传统的模型跑分，但我们可以对比一下 UI 操作与 API 操作的工程效率，并给出落地排查清单。
- UI 操作：单仓库配置耗时约 30 秒，百个仓库需 50 分钟，无法纳入版本控制。
- API 操作：编写脚本批量调用，百个仓库配置耗时小于 10 秒，配置状态可存入 Git 仓库实现基础设施即代码。
针对准备接入这套 API 的团队，我整理了一份落地排查清单。首先，确认你的 GitHub 订阅版本，必须是 GitHub Advanced Security，且环境在 github.com，本地部署的 GitHub Enterprise Server 目前直接报错。其次，检查 API 版本号，调用时务必带上 apiVersion=2026-03-10 参数，否则可能命中旧版逻辑导致字段缺失。最后，在 CI 流水线中集成时，务必做好重试机制与错误日志捕获，特别是针对 409 冲突和 422 参数校验失败这两类常见错误，需要有明确的告警推送到内部通讯工具。
▎官方文档与反馈渠道
要开始使用这两个新端点，你需要查阅最新的 REST API 文档。API 接口详情与 AI 扫描安全检测概念可以参考以下官方链接：
API 接口详情：
AI 扫描安全检测概念：
如果在集成过程中遇到 Bug 或者有功能建议，官方在 GitHub Community 开了专门的讨论帖，可以直接去那里提交反馈：
社区讨论与反馈：
从工程视角来看，GitHub 把 AI 安全扫描 API 化，是 DevSecOps 走向深水区的一个明确信号。以前我们谈安全左移，往往停留在理念层面，因为缺乏自动化的工具链。现在，AI 检测能力变成了可以通过代码调用的标准接口，这让安全策略可以像业务代码一样进行版本控制、代码审查和自动化部署。对于技术决策者而言，下一步应该考虑如何将这套 API 与内部的资产管理系统打通，实现新应用上线时安全扫描策略的自动下发，而不是继续依赖人工配置。
点个赞再走？
你们团队现在的代码安全扫描是手动配置还是已经接入 CI/CD 自动化了？
往期推荐
- ·Qwen3-8B发布，8种推理操作在中间层分离
- ·Anthropic 员工辞职，Agent 越权黑入网站引争议
- ·AI 巨头复刻15年前编程套路，纽约最大学区直接封杀
点击公众号头像 → 历史消息，可翻阅以上文章
