为 SAST/SCA 扫描器收窄仓库权限：从只读令牌到 CI 门禁回归

SAST 与 SCA 扫描器通常只需要读取代码、依赖清单和少量仓库元数据，但服务账号有时会被授予创建分支、写入代码、管理仓库设置等权限。这样一来，扫描器凭证一旦泄露，影响范围就可能从“读取以便分析”扩大到“修改仓库或流水线”。收敛权限时，关键不是简单换成只读令牌，而是先列清扫描所需的数据，再用合并请求门禁验证权限变更没有漏掉扫描对象。

从数据流划定读取范围

SAST 分析团队编写的代码，SCA 检查依赖及其版本信息。扫描器可能从仓库检出代码，也可能由 CI 任务把工作区交给扫描器；具体读取对象取决于扫描方式、语言生态和项目配置。先画出数据流，才能判断令牌是否真的需要访问仓库，以及需要访问哪些内容：

提交或合并请求
        ↓
CI 任务检出代码与依赖清单
        ↓
扫描器读取源文件、锁定文件和配置
        ↓
生成发现结果
        ↓
CI 门禁判断是否允许合并

在检查权限前，逐项记录扫描输入和输出：

最后一行经常造成权限误配：读取源码与写回扫描状态是两种不同需求。应优先让扫描器使用只读身份；若必须回传状态，将该能力交给独立的 CI 身份或单独的短期凭证，并限制到必要的仓库和操作。不要让“扫描器需要显示结果”成为授予代码写入权限的理由。

对照现有授权

盘点令牌所属账号、有效期、仓库范围、权限级别、使用位置和最后使用时间。检查 CI 配置、密钥管理器、仓库变量及扫描器配置，确认实际调用的是哪一个凭证，避免只改了看得见的配置，却留下旧令牌继续生效。

常见的过度授权包括：

• 为了读取代码，给服务账号整个组织或全部仓库的访问权。
• 令牌同时拥有仓库读写权限，即使扫描器只需要检出代码。
• 把扫描结果回传所需的写权限，与扫描器读取源码的身份绑定在一起。
• 令牌长期有效、多人共享，且无法对应到具体流水线或仓库。
• 分析人员和扫描任务共用一个服务账号，导致日常人工操作也继承流水线权限。

建议按“身份—仓库—操作—凭证生命周期”建立清单。至少能回答：哪个任务使用这份凭证、能读哪些仓库、能否写入、凭证何时轮换、谁负责审计。若无法追溯使用者和用途，应先识别依赖关系，再安排替换，不要直接撤销可能仍被生产流水线使用的令牌。

收敛为最小只读权限

准备与基线

先选一个代表性仓库作为试点，记录当前扫描覆盖和门禁结果：被纳入扫描的分支、源文件与依赖清单范围、扫描任务是否成功、结果是否正常回传。对比权限变更前后的结果时，应区分“扫描失败”和“扫描发现安全问题”：前者表示工具未能完成工作，后者才是扫描结论。

同时备好回滚条件：保留当前令牌的权限记录和使用位置，确认可重新签发凭证，并指定恢复负责人。不要在没有替代凭证的情况下直接撤销唯一可用的令牌。

配置只读身份

为扫描任务设置专用服务账号或专用凭证。按仓库平台提供的最细粒度能力，限定可访问的仓库；为源码和依赖分析授予读取所需内容的权限，不授予提交、推送、合并或修改仓库设置的能力。若平台无法将权限细分到某种文件类型，就以仓库级只读作为边界，并通过 CI 检出步骤和扫描配置控制实际分析范围。

若扫描器必须写回检查状态，拆分读取与写入身份：读取凭证只用于检出和分析；写入能力仅由负责发布检查状态的 CI 步骤使用，并限制仓库范围与触发条件。这样，即使扫描器读取凭证泄露，也不会自动获得改写代码的能力。

在分支保护和合并请求策略中，将扫描结果作为检查项，而不是授予扫描器批准或合并权限。分支保护负责限制代码如何进入受保护分支；服务账号权限负责限制流水线能够对仓库执行什么操作。两者互补，不能彼此替代。CI/CD 安全实践也强调对用户、服务账号、运行器和任务分别应用最小权限，并保护仓库与分支。Checkmarx：CI/CD 安全实践

轮换凭证并检查日志

按先新后旧的顺序轮换：创建新的只读凭证，更新密钥管理器或 CI 中的引用，运行试点扫描并确认结果，再撤销旧凭证。不要把令牌直接写进仓库文件、扫描参数日志或构建产物；权限收敛后也要搜索旧凭证的引用位置，避免其他流水线仍依赖它。

检查仓库平台和 CI 系统的审计记录，关注服务账号访问了哪些仓库、何时使用凭证、是否出现写操作或访问失败。审计记录的保留范围和字段因平台配置而异，应确认事件可检索、时间范围足以覆盖轮换前后，并确保告警能交给明确的负责人处理。出现非预期写操作时，先撤销或禁用相关凭证，再核对受影响的仓库、提交和流水线配置。

用合并请求验证扫描覆盖

权限调整后，不要只检查“任务变绿”。合并请求门禁应同时验证扫描任务能否读取代码、扫描范围是否完整、结果能否回传，以及权限是否确实被收窄。

可按以下步骤回归：

1. 在试点仓库提交一项可识别的测试变更，确保它落在原有 SAST 分析范围内；另选择一项会改变依赖清单的变更，验证 SCA 能读取对应文件。测试内容应使用团队批准的安全测试样例，不要为验证门禁而提交真实漏洞或秘密。
2. 发起合并请求，确认 CI 能检出目标提交和必要的目标分支信息，SAST 与 SCA 均完成预期分析。
3. 检查扫描范围、报告或平台检查结果，确认依赖文件没有因权限错误、路径变化或配置过滤而漏扫。
4. 验证门禁策略：扫描任务失败时，合并请求应按团队策略阻断或进入明确的人工处置流程；扫描发现达到阻断条件的问题时，也应产生预期检查结果。不要把“扫描器无权限而跳过检查”当作通过。
5. 用扫描服务账号尝试验证其不能执行不需要的写操作，例如修改受保护分支或提交代码。应在测试仓库或经批准的安全测试流程中验证，避免对生产分支做破坏性尝试。
6. 检查审计记录，确认新凭证只被预期任务使用，旧凭证已撤销，且没有遗留写权限。

判定结果时，将扫描覆盖、扫描执行成功、门禁决策和权限验证分开记录。若扫描器报告权限不足，先确认缺失的是必需读取能力还是非必要的写回能力；只补上完成扫描所需的最小权限，并重新运行上述回归。不要因为任务失败就恢复到组织级读写令牌。

门禁失败时的回滚与修复

权限调整导致流水线无法完成扫描时，先暂停相关合并或发布路径，保存失败日志、扫描配置版本和凭证变更记录。随后定位故障是在仓库检出、目标分支读取、依赖清单访问，还是结果回传阶段。按具体失败环节修复对应权限或任务配置，避免一次性放宽整个服务账号。

如果必须短暂恢复旧凭证以恢复业务，应限定到受影响的仓库和任务，设置明确的撤销时间，并保持受保护分支与审批要求。恢复期间记录使用者和用途；故障排除后重新签发最小权限凭证、再次轮换，并补跑完整的合并请求回归。回滚是恢复服务的临时措施，不应成为长期权限状态。

最终应留下可复核的证据：权限清单、变更审批、凭证轮换记录、门禁回归结果和审计检查结论。这样，最小权限不仅体现在令牌配置上，也能通过持续运行的 SAST、SCA 与 CI/CD 安全门禁证明没有牺牲扫描覆盖。