CI/CD 流水线安全实战从 OWASP 十大风险到发布门禁设计专栏代码安全笔记 · 软件供应链安全进阶篇09关键词CI/CD 安全、DevSecOps、Pipeline、GitHub Actions、权限最小化摘要CI/CD 系统往往持有源代码读写权限、构建凭据、制品仓库访问令牌甚至生产部署能力。一旦流水线被攻击者利用攻击面可能从单一项目扩展到整个软件发布链。本文以 OWASP Top 10 CI/CD Security Risks 为基础讲解配置审查、身份权限、密钥管理和制品完整性验证的实践方法。一、CI/CD 为什么是高价值攻击目标传统开发环境中攻击者可能只触及一台开发机而具有广泛权限的流水线可能接触多个仓库、镜像仓库与生产账户。代码仓库CI 触发器构建执行器安全扫描制品仓库生产环境凭据/令牌第三方 Action/插件外部依赖重点不是“流水线中有多少安全工具”而是它能否阻断未经授权的变更和不可信的构建产物。二、OWASP CI/CD 十大风险速览编号风险类型建议控制CICD-SEC-1流程控制不足受保护分支、发布审批CICD-SEC-2身份与访问管理不足最小权限、独立身份CICD-SEC-3依赖链滥用可信源及依赖校验CICD-SEC-4流水线执行被污染隔离不可信输入CICD-SEC-5流水线权限控制不足作业级、环境级授权CICD-SEC-6凭据卫生不足短期凭据、禁止泄露CICD-SEC-7系统配置不安全执行器加固与更新CICD-SEC-8第三方服务失控插件准入与版本固定CICD-SEC-9制品完整性校验不足摘要、签名及验证CICD-SEC-10日志与可见性不足集中审计与异常告警以上为中文意译正式名称及解释以 OWASP 官方原文为准。三、GitHub Actions 基线示例以下示例用于展示只读权限、锁定操作版本、扫描和构建分离等设计原则SHA 均为占位符使用前必须替换为官方发布版本的完整可信提交哈希name:build-checkon:push:branches:[main]pull_request:permissions:contents:readjobs:verify:runs-on:ubuntu-lateststeps:-name:Checkoutuses:actions/checkoutPINNED_FULL_COMMIT_SHA-name:Dependency installrun:npm ci-name:Testrun:npm test--if-present-name:Buildrun:npm run build--if-present重要PINNED_FULL_COMMIT_SHA是占位符示例不可原样执行。正式环境应同时检查 Action 的维护主体、必要权限、网络策略和第三方依赖。若工作流需要部署权限应将其隔离到独立作业并使用环境审批等控制。四、四道发布门禁门禁一代码来源对主分支启用代码审查、状态检查、强制审批保护工作流配置文件。避免未审查的外部贡献直接进入可访问生产密钥的任务。门禁二依赖与构建环境在 CI 中使用锁文件、一致性安装、可信包源、隔离执行器针对第三方 Action、构建镜像和工具链进行版本固定与准入。门禁三安全检测根据项目风险设置秘密扫描、SAST、SCA、容器镜像扫描和许可证检查。对高风险结果建立阻断规则同时保留误报处理和限期豁免机制。门禁四制品与部署构建产物进入受控仓库绑定 SHA-256 摘要与来源证明。部署系统只允许拉取经过批准并验证身份的制品拒绝“本地打包后手工覆盖生产文件”。五、凭据管理的关键细节能使用短期令牌和身份联合的场景优先避免长期静态密钥对 PR、Fork 和不可信分支采用不同权限模型不把密钥打印到日志、构建缓存或错误报告将部署账户限制在单一环境不与 CI 管理员权限混用定期演练凭据泄露后的吊销与重新发布。六、监控什么才有价值建议监控高权限工作流变更、令牌创建与使用、异常执行器注册、制品重新发布、跨环境部署及失败的签名验证。每条告警应可以追溯到仓库、提交、执行任务、主体身份和具体制品。七、落地检查清单[ ] 默认 CI 权限是否为最小权限 [ ] 第三方 Action 是否固定可信版本/提交 [ ] 外部 PR 是否无法直接读取生产密钥 [ ] 流水线修改是否受到代码审查 [ ] 制品是否有哈希、签名或来源证明 [ ] 部署是否验证产物身份而非仅验证文件名 [ ] 日志是否覆盖身份、构建、发布关键事件总结CI/CD 安全不是往流水线里无限堆扫描器而是控制谁能改变流水线、流水线能访问什么、最终制品是否可信。最值得优先建设的能力是最小权限、隔离执行、可信依赖、来源验证和可追溯审计。