T1677: 管道投毒执行

摘要

攻击者可能通过将恶意代码注入构建过程来操纵持续集成/持续开发（CI/CD）流程。有几种对管道投毒的机制： * 在 <b>直接管道执行</b>场景中，威胁行为者直接修改 CI 配置文件（例如，GitLab 中的 `gitlab-ci.yml`）。他们可能包含一个命令，将构建过程中使用的凭据外泄到远程服务器，或将其导出为工作流产物。(Citation: Unit 42 Palo Alto GitHub Actions Supply Chain Attack 2025)(Citation: OWASP CICD-SEC-4) * 在 <b>间接管道执行</b>场景中，威胁行为者将恶意代码注入 CI 配置文件所引用的文件中。这些文件可能包括 makefile、脚本、单元测试和 linter。(Citation: OWASP CICD-SEC-4) * 在 <b>公共管道执行</b>场景中，威胁行为者没有对仓库的直接访问权限，而是从分叉创建一个触发 CI/CD 管道某一部分的恶意拉取请求。例如，在 GitHub Actions 中，`pull_request_target` 触发器允许从分叉仓库运行的工作流访问机密。如果此触发器与显式的拉取请求检出以及威胁行为者可插入恶意代码的位置（例如 `npm build` 命令）结合，威胁行为者可能能够泄露管道凭据。(Citation: Unit 42 Palo Alto GitHub Actions Supply Chain Attack 2025)(Citation: GitHub Security Lab GitHub Actions Security 2021) 类似地，如果构建管道将某些输入视为受信任的，威胁行为者可能构造带有恶意输入（如分支名称）的拉取请求。(Citation: Wiz Ultralytics AI Library Hijack 2024)(Citation: Synactiv Hijacking GitHub Runners)(Citation: GitHub Security Labs GitHub Actions Security Part 2 2021) 最后，如果管道利用自托管运行器，威胁行为者可能能够在组织网络内的主机上执行任意代码。(Citation: John Stawinski PyTorch Supply Chain Attack 2024) 通过对 CI/CD 管道投毒，威胁行为者可能能够获取凭据的访问权限、横向移动到其他主机，或注入恶意组件以沿着管道进一步传递（即[供应链攻陷](https://attack.mitre.org/techniques/T1195)）。