9.2 流水线控制面：短期身份、Policy as Code 与运行时反馈

发布流水线握有进入生产的通行证，一枚长期密钥泄露就可能绕过前面所有审核。

CI/CD 同时能读取源码、签发制品和修改生产环境。专用 secret vault 能提供访问控制、审计和轮换，优于硬编码，但其中的长期云密钥泄露后仍可持续被使用。支持联邦身份时，可让每个 job 用受验证工作负载身份换取短期、窄权限凭据。

联邦身份替代长期云密钥

CI job identity token
  claims: issuer, repository, workflow, ref, environment
        ↓ cloud STS policy validation
short-lived credential scoped to one deployment action

云端要验证签名、时效、精确 issuer 和 audience，并按实际 CI/云提供者支持的 claims 约束仓库/组织、受信 workflow、受保护分支或 environment。不要只解码 JWT 就使用字段；不同平台或仓库的 subject 格式也可能变化。只校验“来自某 CI 平台”会让平台上其他仓库也能换取权限。

开发 PR job、构建 job 和生产发布 job 使用不同身份。生产角色不应允许任意分支 assume，凭据按操作需求取支持的最短有效期，并记录换取主体与使用事件。CI 身份 token 和 STS 换出的云凭据有各自的时限；job 结束不保证已复制的云凭据立刻失效，还需限制权限和到期前的剩余暴露窗口。

Secret scanning 覆盖历史和衍生物

服务端 push protection 在推送入库前检查支持的 token 格式；本地提交前检查需要 pre-commit 等独立机制。覆盖范围受 token 类型、配置与绕过权限影响，但秘密还会出现在 Git 历史、构建日志、测试 fixture、缓存、镜像 layer 和 artifact。发现泄露后先撤销/轮换，再按影响范围清理历史与衍生副本；只删除当前文件不会让已复制的秘密失效。

某些 CI 会屏蔽已登记 secret，具体能力需要验证；但攻击者可编码、分片或写入 artifact 绕过 masking。根本控制仍是不给不可信 job secret，并限制 job 的出站和 artifact 上传权限。

Policy as Code 把决策变成可测试输入

策略可检查：

生产镜像必须使用 digest；
禁止 privileged 与 hostPath；
公网服务必须有 owner、TLS 与限流；
制品必须有受信 builder provenance；
高敏数据存储必须启用指定加密与日志策略。

策略 repository 需要版本、测试、评审与 rollout；使用 CODEOWNERS 时，还必须启用对应的受保护分支/规则，单放一个文件不会强制审批。应分别测试允许、拒绝、字段缺失、类型错误和验证器不可用，不能把“没执行策略”当成允许。先在 audit 模式观察现有资源，再阻断新增违规，最后治理存量。错误的全局 deny 可能让紧急恢复也无法执行，因此要设计受审计 break-glass，而不是永久 bypass 账户。

工具运行权限遵循最小化

SAST 通常只需源码读取；SCA 不应自动执行依赖安装脚本；DAST 对测试环境需要受限网络与测试账户；IaC plan 应尽量使用只读云权限，但生成 plan 可能执行 provider、外部数据源或其他程序，还可能需要后端状态锁权限。它不是处理不可信 IaC 的无副作用沙箱；apply 再单独获取所需写权限，state 与 plan 文件也要按敏感数据保护。

第三方 CI action/plugin 是执行代码依赖，应固定不可变 revision、审查权限和更新来源。扫描器本身处理攻击者控制的源码和制品，也需要及时更新和 sandbox。

Shift Right 补上真实运行条件

运行时反馈用于发现：未在测试覆盖的攻击路径、配置漂移、实际加载依赖、异常权限使用和新的利用情报。它不代表在生产中“先发布再找漏洞”。

runtime event
→ artifact digest / source revision
→ owning team and threat
→ containment
→ regression test / policy / secure default

若事件只停在 SIEM，不回到代码与平台控制，同类问题还会重复。反过来，也不要把每个内核 syscall 告警直接建成开发 P0；需要关联资产关键度、身份、网络和用户影响。

发布控制面检查

• 外部 PR 能否接触 secret、持久 runner 或发布网络？
• 每个 job 的 token audience、subject、权限和期限是否最小？
• Policy 变更是否测试、评审、渐进启用并可安全回退？
• 发布是否只接受已验证 digest，而非 mutable tag？
• 谁能修改 workflow、environment protection 和 signing policy？
• 运行时事件能否定位源 revision、SBOM、owner 和修复部署？

下一章深入制品证据：SBOM 说明包含什么，provenance 记录怎样构建，签名与验证策略决定能否接受。

参考资料

• NIST, SP 800-218 SSDF 1.1
• OpenID Foundation, OpenID Connect Core
• OWASP, Secrets Management Cheat Sheet