GitHub 遭入侵凸显 CI/CD 供应链风险

数千个仓库使用的一个热门 GitHub Action 最近遭到入侵，暴露了开源 Action 发布和使用方式中的一个关键漏洞。

一位新加入的维护者通过发布一个包含了混淆恶意代码的版本，短暂劫持了 tj-actions/changed-files Action。这引发了开发者社区对 GitHub Actions 生态系统中 CI/CD 安全性的担忧。

此次事件让人们注意到了一个新兴的攻击面：Action 本身的供应链。大多数和 Action 相关的指南都侧重于优化工作流环境，很少有团队仔细审查他们导入的 Action 的安全性。这一漏洞让业内人士再次呼吁大家重视最佳实践，如 Action 固定、第三方审计和强化运行器等。

很多代码库广泛使用 tj-actions/changed-files Action 来检测拉取请求中的文件更改——这是一些 CI 工作流中的常见步骤。2025 年 3 月，一位新的维护人员引入了一个版本 (v44)，其中包含了可由远程代码执行的混淆 shell 命令。虽然该恶意版本存在的时间很短，但它毕竟绕过了检测，暴露出了有大量开发者信任并使用 Gi​​tHub Actions 这一盲点。

当用户注意到该动作的新版本包含一个混淆的 curl | bash 模式时，该漏洞才得以曝光——这被认为是远程脚本执行的危险信号。StepSecurity 分析了其中的代码，并确认它可以从 GitHub 托管的运行器中窃取敏感数据。这个恶意版本被迅速移除，代码库也恢复了。该事件让受影响的众多项目开始了广泛的审计，并暂停了工作流。

这一 Action 之所以引人注目，不仅是因为它的受欢迎程度——据估计有超过 2 万个代码库使用了它——还因为它暴露了更广泛的生态系统存在的一大弱点。开发者通常将 GitHub Actions 视为值得信赖的构建块，但与软件包或容器不同，Actions 缺乏对发布、所有权变更或签名验证的强大控制力。

安全研究人员和开源维护人员迅速分享了各种缓解措施。StepSecurity 建议将所有第三方动作固定到特定的 SHA，以确保可重复性并防止篡改。他们还建议通过限制出站网络访问、严格限定环境变量范围以及减少不必要的权限来强化 GitHub 托管的运行器。此事件还促使一些开发人员采取主动行动——扫描其工作流中未固定的依赖项，并审核其所依赖的工作流。

除了一些代码库受到影响外，此次事件重新引发了关于 CI/CD 供应链安全性的更广泛讨论。开发者论坛中出现了担忧，行业研究者也对攻击的潜在影响范围做了更深入的分析。许多团队专注于保护其应用程序代码（包括依赖项扫描和静态分析等实践），而 CI/CD 工具的审查可能较少。GitHub Actions 尤其特别，它们以高权限运行，能够签署发布、推送镜像或部署到生产环境。一个被入侵的动作可能会破坏整个交付流程。虽然 StepSecurity 并未量化使用未固定 Actions 的普遍性，但他们经常强调其使用风险，并建议大家谨慎对待。

这次威胁也让人想起了其他生态系统中类似的问题，例如恶意 NPM 包或木马 Docker 镜像。尽管业界正在通过 SLSA、Sigstore 和 SBOM 工具等举措取得进展，但 GitHub Actions 仍然缺乏对可重用 Actions 的溯源、沙盒或信任执行的一流支持。

随着对 GitHub Actions 生态系统的审查日益严格，一些工程团队开始规范其评估和采用第三方自动化工具的方式，为可信 Actions 定义内部标准，并在集成动作前进行审核。这种基于护栏的方法，正如 Salesforce 等组织所见，反映了一种更广泛的转变，即将长期以来对应用程序依赖项的谨慎和治理态度用于 CI/CD 基础设施上。它也暗示了这一生态系统的未来发展方向。

原文链接：

Compromised GitHub Action Highlights Risks in CI/CD Supply Chains