GitHub AI Scan：组织级设置，仓库级例外

1. 在组织和仓库层面管理设置

GitHub 于 2026年11月13日表示，已在现有 AI 扫描启用功能中新增是否扫描整个仓库的选项。新属性 repository_scan 接受启用或禁用两种状态。可向组织或仓库发送查询或修改请求进行管理。

此前的设置面向拉取请求扫描，拉取请求是提交代码变更以供审查的功能。此次新增的全仓库扫描设置可与现有设置在同一请求中修改。新设置也遵循现有的组织与仓库继承规则，即下级继承上级设置的原则。

如果组织禁用该设置，其下属仓库就无法开启。如果组织启用，仓库将继承设置，管理员可选择性地在个别仓库中关闭。因此，可以将中央策略作为默认值应用，同时单独管理例外仓库。

2. 减少部署工作并管理执行成本

设置部署与实际扫描执行分为两个步骤。管理员确定可用范围后，具有写入权限的用户可在需要时请求执行扫描。每次扫描都会消耗 GitHub Code Security AI 额度，即按使用量扣减的计费单位。

通过 API 自动完成重复设置，可减少逐个打开仓库修改的工作量，也更容易一致地应用团队制定的策略。但实际执行会消耗额度，因此除了部署设置时节省的管理工作，还需单独处理执行成本。在运维中，应同时确定批量启用的仓库范围和负责执行的用户。

3. 确认适用对象与权限

组织所有者和安全管理员可管理组织设置，仓库管理员可调整单个仓库的设置。使用细粒度令牌，即精细限定权限范围的认证密钥时，修改组织设置需要组织管理写入权限，修改仓库设置需要仓库管理写入权限。查询仓库设置需要代码扫描警报读取权限，警报用于通知代码中发现的安全问题。

组织拥有的公开仓库可以使用此功能，私有或内部仓库则需要 GitHub Code Security 或 GitHub Advanced Security。应用流程首先要求企业所有者在策略中允许 AI 扫描。

4. 在一次请求中应用设置的方法

组织路径和仓库路径均支持查询与修改设置。组织使用 /orgs/{org}/code-scanning/ai-scan，单个仓库使用 /repos/{owner}/{repo}/code-scanning/ai-scan。

查询使用 GET 请求，修改使用 PATCH 请求。以下是原文中在组织层面同时启用拉取请求扫描和全仓库扫描的示例。使用时需根据自身环境指定认证令牌和组织名称。

curl -L \
  -X PATCH \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/orgs/ORG/code-scanning/ai-scan \
  -d '{"pr_scan":"enabled","repository_scan":"enabled"}'

请求成功后，响应会包含两项设置的状态。将要一并修改的设置放在同一请求中发送，即可在响应中确认两个值，也能合并变更后的状态检查步骤。

若企业策略阻止启用或值验证失败，则返回 422 错误；同时修改两项设置时，只要其中一项受阻，两项都会保留原值。若仓库处于归档状态，即以禁止修改的方式保存，或未启用 GitHub Advanced Security，仓库修改请求可能返回 403 错误；GitHub Enterprise Server 不在支持范围内。

5. 通过查询结果检查组织设置与例外

组织查询响应显示保存在组织中的设置值，而组织实际应用的设置还会受到企业策略影响。因此，管理员可按先确认上级策略、再部署组织设置、最后逐个查询仓库以检查各自设置的顺序制定运维流程。

结合组织与仓库的查询路径，可在各层级确认中央制定的默认值和各仓库选择的例外。向多个仓库推广功能时，将确认步骤与设置变更一起纳入脚本也很实用。

同时提供组织级设置与仓库级例外，可简化部署管理，但扫描执行与额度管理仍需单独规划。