12 KiB
Pentesting CI/CD Methodology
{{#include ../banners/hacktricks-training.md}}
VCS
VCS 代表 Version Control System，这个系统允许开发者 管理他们的源代码。最常见的是 git，你通常会发现公司在以下 platforms 中使用它：
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (他们提供自己的 VCS platforms)
CI/CD Pipelines
CI/CD pipelines 使开发者能够为各种目的 自动执行代码，包括构建、测试和部署应用程序。这些自动化工作流会被 特定操作触发，例如代码推送、pull requests，或定时任务。它们有助于简化从开发到生产的流程。
然而，这些系统需要在 某个地方执行，而且通常需要 特权凭证 来部署代码或访问敏感信息。
VCS Pentesting Methodology
Note
即使某些 VCS platforms 允许创建 pipelines，我们在这一部分也只分析对源代码控制的潜在攻击。
包含项目源代码的平台会包含敏感信息，因此人们必须非常谨慎地管理授予该平台内的权限。以下是攻击者可能利用的一些常见 VCS platform 问题：
- Leaks: 如果你的代码在 commits 中包含 leaks，并且攻击者能够访问 repo（因为它是公开的，或者因为他有访问权限），他就可以发现这些 leaks。
- Access: 如果攻击者能够 访问 VCS platform 中的一个账户，他就可能获得 更多可见性和权限。
- Register: 某些 platforms 允许外部用户直接创建账户。
- SSO: 某些 platforms 不允许用户注册，但会允许任何拥有有效 SSO 的人访问（例如攻击者可以用他的 github 账户进入）。
- Credentials: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies... 有多种 token，用户可能会窃取这些 token 以某种方式访问 repo。
- Webhooks: VCS platforms 允许生成 webhooks。如果它们 没有 使用不可见的 secrets 进行保护，攻击者就可以滥用它们。
- 如果没有设置 secret，攻击者就可以滥用第三方 platform 的 webhook
- 如果 secret 在 URL 中，情况也一样，而且攻击者还能拿到该 secret
- Code compromise: 如果恶意行为者对 repos 拥有某种 write 访问，他可能会尝试 注入恶意代码。为了成功，他可能需要 绕过 branch protections。这些操作可能出于不同目的：
- 破坏 main branch 以 破坏生产环境。
- 破坏 main（或其他 branches）以 破坏开发者机器（因为他们通常会在自己的机器上在 repo 内执行测试、terraform 或其他内容）。
- 破坏 pipeline（见下一节）
Pipelines Pentesting Methodology
定义 pipeline 最常见的方法，是使用一个 托管在 pipeline 构建的 repository 中的 CI configuration file。这个文件描述已执行 jobs 的顺序、影响流程的条件，以及构建环境设置。
这些文件通常具有一致的名称和格式，例如 — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)，以及位于 .github/workflows 下的 GitHub Actions YAML files。被触发时，pipeline job 会从所选 source（例如 commit / branch）拉取代码，并针对该代码 运行 CI configuration file 中指定的 commands。
因此，攻击者的最终目标是以某种方式 破坏这些 configuration files 或 它们执行的 commands。
Tip
Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
{{#ref}} docker-build-context-abuse.md {{#endref}}
PPE - Poisoned Pipeline Execution
Poisoned Pipeline Execution (PPE) 路径利用 SCM repository 中的权限来操纵 CI pipeline 并执行有害 commands。拥有必要权限的用户可以修改 CI configuration files 或 pipeline job 使用的其他 files，以包含恶意 commands。这样就“污染”了 CI pipeline，导致这些恶意 commands 被执行。
要成功执行 PPE attack，恶意行为者需要能够：
- 在 VCS platform 上拥有 write access，因为通常 pipelines 会在 push 或 pull request 被执行时触发。（查看 VCS pentesting methodology 以了解获取访问权限的方式总结）。
- 注意，有时 external PR 也算作 "write access"。
- 即使他有 write permissions，他也需要确保自己能够 修改 CI config file 或 config 依赖的其他 files。
- 为此，他可能需要能够 绕过 branch protections。
PPE 有 3 种形式：
- D-PPE: 当行为者 修改 将要执行的 CI config 文件时，会发生 Direct PPE attack。
- I-DDE: 当行为者 修改 将要执行的 CI config file 所 依赖 的某个 file 时，会发生 Indirect PPE attack（例如 make file 或 terraform config）。
- Public PPE or 3PE: 在某些情况下，pipelines 可以被 没有 repo write access 的用户触发（他们甚至可能不属于该 org），因为他们可以发送 PR。
- 3PE Command Injection: 通常，CI/CD pipelines 会 设置 environment variables，其中包含有关 PR 的 信息。如果该值可被攻击者控制（例如 PR 的标题），并且在 危险位置 被 使用（例如执行 sh commands），攻击者可能会在其中 注入 commands。
Exploitation Benefits
了解污染 pipeline 的 3 种形式后，接下来看看攻击者在成功利用后可以获得什么：
- Secrets: 如前所述，pipelines 的 jobs 需要 权限（检索代码、构建、部署等），而这些权限通常以 secrets 形式授予。这些 secrets 通常可以通过 env variables 或系统内的 files 访问。因此，攻击者总会尝试尽可能多地外传 secrets。
- 根据 pipeline platform 的不同，攻击者 可能需要在 config 中指定 secrets。这意味着如果攻击者无法修改 CI configuration pipeline（例如 I-PPE），他就 只能外传该 pipeline 已有的 secrets。
- Computation: 代码会在某处执行，根据执行位置，攻击者可能能够进一步 pivot。
- On-Premises: 如果 pipelines 在本地环境执行，攻击者可能最终进入一个 内部网络，并访问更多资源。
- Cloud: 攻击者不仅可以访问 cloud 中的 其他 machines，还可以从中 外传 IAM roles/service accounts tokens，以获得 cloud 内部的进一步访问权限。
- Platforms machine: 有时 jobs 会在 pipelines platform machines 内执行，这些机器通常位于一个 cloud 中，并且 没有更多访问权限。
- Select it: 有时 pipelines platform 会配置多台 machines，如果你能 修改 CI configuration file，你就可以 指定想要在哪台机器上运行恶意代码。在这种情况下，攻击者很可能会在每一台可能的机器上运行 reverse shell，以尝试进一步利用它。
- Compromise production: 如果你在 pipeline 中，并且最终版本是从那里构建和部署的，你就可以 破坏最终会在 production 中运行的代码。
Dependency & Registry Supply-Chain Abuse
破坏 CI/CD pipeline 或从中窃取凭证，可能让攻击者通过后门化 dependencies 或 release tooling，从 pipeline execution 转向 ecosystem-wide code execution：
- Install-time code execution via package hooks: 发布一个 package version，添加
preinstall、postinstall、prepare或类似 hooks，使 payload 在 dependency installation 期间自动在开发者工作站和 CI runners 上运行。 - Secondary execution paths: 即使目标使用
--ignore-scripts安装，恶意 package 仍可在bin字段中注册一个 common CLI name，从而将攻击者控制的 wrapper 通过 symlink 放入PATH，并在之后命令被使用时执行。 - Runtime bootstrapping: 一个小型 installer 可以在安装期间下载第二个 runtime 或 toolchain（例如 Bun 或一个打包好的 interpreter），然后用它启动主 payload，从而避免本地依赖要求。
- Credential harvesting from build environments: 一旦 code 在 CI 中运行，检查 environment variables、
~/.npmrc、~/.git-credentials、SSH keys、cloud CLI configs，以及像gh auth token这样的本地工具。在 GitHub Actions 中，也要查找 runner-specific secrets 和 artifacts。 - Workflow injection with stolen GitHub tokens: 拥有
repo+workflowpermissions 的 token 足以创建一个 branch，在.github/workflows/中提交一个恶意文件，触发它，收集生成的 artifacts/logs，然后删除临时 branch/workflow run 以减少痕迹。 - Wormable registry propagation: 被窃取的 npm tokens 应验证是否具有 publish 权限以及是否绕过 2FA。如果可以，枚举可写 packages，下载它们的 tarballs，注入一个类似
setup.mjs的 loader，将preinstall设为执行它，提升 patch version，并重新发布。这样就会把一次 CI compromise 变成其他环境中的下游自动执行。
Practical checks during an assessment
- 审查 release automation 是否在
package.json中添加了 package-manager hooks、意外的binentries，或只修改 release artifact 的 version bumps。 - 检查 CI 是否将长期存在的 registry credentials 以明文文件形式存储，例如
~/.npmrc，而不是使用短期 OIDC 或 trusted publishing。 - 验证 CI 中可用的 GitHub tokens 是否能够写入 workflow files 或创建 branches/tags。
- 如果怀疑某个 package 已被 compromise，请检查已发布的 tarball，而不仅仅是 Git repository，因为恶意 loader/runtime 可能只存在于已发布的 artifact 中。
- 在 CI 中排查意外的 package-manager execution，例如使用
npm install而不是npm ci、意外的 Bun downloads/execution，或由临时 branches 生成的新 workflow artifacts。 - 也要将 GitOps deployment engines 视为 CI/CD targets。Argo CD-specific enumeration、repo-server abuse 和 Redis cache poisoning attacks 在 Argo CD Security 中有介绍。
More relevant info
Tools & CIS Benchmark
- Chain-bench 是一个开源工具，用于根据新的 CIS Software Supply Chain benchmark 审计你的 software supply chain stack 的安全合规性。该审计关注整个 SDLC process，并能揭示从 code time 到 deploy time 的风险。
Top 10 CI/CD Security Risk
查看这篇有趣的文章，了解 Cider 评出的 CI/CD top 10 risks: https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
- 在每个平台上，如果你可以在本地运行，你都会找到如何在本地启动它的方法，这样你就可以按需配置它来进行测试
- Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat
Automatic Tools
- Checkov: Checkov 是一个用于 infrastructure-as-code 的静态代码分析工具。
References
- https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422
- The npm Threat Landscape: Attack Surface and Mitigations
- Checkmarx Security Update: April 22, 2026
{{#include ../banners/hacktricks-training.md}}