GitHub 代码扫描的 PR AI Scan 进入公开预览，可用 REST API 管理

你现在可以通过组织级和仓库级的 REST API 端点，管理 GitHub 代码扫描中拉取请求 AI Scan 的启用。

这一公开预览为团队提供了一种程序化方式，在选定的仓库中为拉取请求推出 AI 驱动的安全检测，而无需在 GitHub UI 中手动配置每一项设置。

使用新的组织和仓库 API 来读取并更新拉取请求的 AI Scan 是否已启用。

组织设置控制拉取请求扫描能否在整个组织中运行，仓库设置则允许为单个仓库开启或关闭扫描。

仓库设置不会覆盖组织级的禁用状态。

要查看和更新选定仓库的 AI Scan 状态，用户可以使用 /orgs/{org}/code-scanning/ai-scan 和 /repos/{owner}/{repo}/code-scanning/ai-scan 端点。

这一公开预览在 github.com 上面向 GitHub Advanced Security 客户提供。

本次发布不支持 GitHub Enterprise Server。

更多信息，请参阅 AI Scan 安全检测。

在 GitHub Community 中加入讨论，并对该公告留下反馈。

GitHub 为代码扫描中的拉取请求 AI Scan 开放了组织级与仓库级 REST API，公开预览阶段允许团队以程序化方式批量开启或关闭 AI 驱动的 PR 安全检测，取代逐仓库手动配置；组织级禁用优先于仓库级设置，本次仅面向 github.com 上的 GitHub Advanced Security 客户，不支持 GitHub Enterprise Server。

• GitHub 为代码扫描中的拉取请求 AI Scan 开放了组织级与仓库级 REST API，公开预览阶段允许团队以程序化方式批量开启或关闭 AI 驱动的 PR 安全检测，取代逐仓库手动配置；组织级禁用优先于仓库级设置，本次仅面向 github.com 上的 GitHub Advanced Security 客户，不支持 GitHub Enterprise Server。
• 原贴提到：You can now manage GitHub code scanning’s AI Scan for pull request enabl
• 来源：github.blog

这是什么信号

GitHub 把代码扫描里 AI Scan 的拉取请求开关，从纯 UI 配置项变成了可编程的 REST API 资源，而且同时提供了组织级和仓库级两个层级。表面看只是多了两个端点，实质上是把这个 AI 安全能力正式纳入了「可被自动化治理」的范畴。以往这类新功能上线，通常先只能靠人点设置页，等社区呼声起来才补 API；这次公开预览阶段就给了 API，说明 GitHub 把 AI 安全检测当成企业级基础设施在做，而不是一个可选项。

另一个值得注意的细节是权限模型：组织设置决定 PR 扫描能否在组织范围内运行，仓库设置只在组织允许的前提下生效，无法覆盖组织级的禁用。这是典型的「组织兜底、仓库细分」的两层策略，和分支保护、Actions 权限等企业治理逻辑一脉相承。

为什么重要

安全能力的落地瓶颈往往不在检测本身，而在开关的分发。一个组织有几百上千个仓库，靠人工逐个勾选开启 AI 扫描，既慢又容易遗漏，更无法保证后续新仓库自动继承策略。有了 API，安全策略就可以进入脚本、CI 流程或配置管理工具，变成可重复执行、可审计、可版本化的动作。

同时，可读取状态意味着可以做「漂移检测」：定期扫描所有仓库的 AI Scan 状态，发现被误关的仓库并自动纠正。这种能力在合规审计场景里比单纯的开关更有价值。

对谁有价值

• 平台工程与 DevEx 团队：需要为整个组织统一推送安全基线，而不是等各团队自助配置。
• 应用安全与 DevSecOps 团队：需要把 AI 检测覆盖率和 PR 门禁纳入度量与报表。
• 合规与审计角色：需要证明安全扫描在选定仓库范围内处于开启状态，并有据可查。
• 已经在用 GitHub Advanced Security 的组织：这是既有许可内的能力扩展，增量成本主要来自接入工作。

可以怎么行动

1. 先用读取端点盘点现状：拉出目标组织下各仓库的 AI Scan 启用情况，形成基线清单，识别该开未开的仓库。
2. 决定治理层级：如果希望全组织默认开启，先确认组织级设置未被禁用——因为仓库级无法突破这一层。
3. 把启用动作脚本化：将调用封装成幂等脚本，纳入新仓库创建流程或定期任务，避免后续仓库再次漏配。
4. 对新仓库做增量覆盖：把调用挂到仓库模板或初始化流水线上，让策略随仓库生命周期自动继承。
5. 建立定期核对：用读取端点做周期性比对，记录状态变化，作为安全覆盖率的证据。

风险与限制

这是公开预览功能，接口行为、字段与端点路径在正式发布前都可能调整，把它写进强依赖的生产流水线前需要留出兼容与回退方案。功能可用范围也有明确边界：只在 github.com 上对 GitHub Advanced Security 客户开放，GitHub Enterprise Server 本次不支持，自托管实例的组织无法使用这套 API。此外，组织级禁用是硬性上限，仓库级设置只能在其之下做精细控制，如果组织策略本身关闭，逐仓库调用不会有任何实际效果——在自动化脚本里应先检查组织状态，避免产生「执行成功但未生效」的假象。因此，把开关打开也不等于检测结果一定有效，仍需观察 PR 上的实际告警质量与误报情况。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《GitHub 代码扫描的 PR AI Scan 进入公开预览，可用 REST API 管理》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖