GitHub Actions因其设计缺陷成为开源供应链安全中最薄弱环节。过去18个月的多起安全事件都源于Actions工作流配置问题，如恶意代码注入、凭证泄露等。Actions作为无锁定文件、无完整性校验的"包管理器"，每次执行都会重新解析可变依赖，加上各功能模块可随意组合，导致安全隐患频发，威胁全球开源项目构建与发布流程。

标题：GitHub Actions成为供应链中最薄弱的一环

过去18个月中，几乎每一起开源供应链安全事件都可追溯至.github/workflows目录下的YAML配置文件。从Ultralytics向PyPI推送加密货币挖矿程序，到nx软件包将数千开发者设备变成凭证收集器；从tj-actions泄露23,000个仓库密钥，到Trivy三周内两次被入侵；再到elementary-data在陌生用户评论后十分钟发布恶意组件——这些事件虽然攻击方式和目标各异，但都利用了GitHub Actions按文档设计运行的功能特性。

核心问题在于： 1. GitHub Actions作为没有锁文件、完整性校验和依赖可见性的包管理器，其uses:声明会针对可变git标签重复解析 2. 平台默认配置本是为企业私有仓库CI设计，却被广泛用于匿名分叉和随意提交的公开项目

典型攻击案例： - 2024年11月spotbugs事件：攻击者通过pull_request_target触发器获取维护者PAT凭证，四个月后利用该凭证入侵tj-actions - Ultralytics缓存投毒：恶意PR污染缓存，最终在构建环节执行挖矿程序 - 2025年3月tj-actions事件：攻击者篡改reviewdog的v1标签，导致23,000个下游仓库运行内存窃取程序 - nx构建系统事件：PR标题被注入shell命令，最终导致5000多个私有仓库被公开 - 2026年prt-scan行动：攻击者针对错误配置的仓库发起数百个PR - Trivy两次被入侵：攻击者强制推送历史版本标签 - elementary-data事件：两日龄账号通过issue评论触发恶意构建

共性漏洞特征： - pull_request_target和issue_comment触发器以完整权限运行不可信代码 - $扩展在shell脚本中未加引号直接替换 - 默认具备写权限的GITHUB_TOKEN - 可变的git引用作为action版本 - 跨信任边界的缓存

行业影响： 主流软件包仓库（PyPI/npm/RubyGems/crates.io）已普遍采用基于OIDC的CI可信发布机制，这使得注册表的安全性实质上取决于GitHub Actions工作流的可靠性。虽然GitHub已公布包含真正修复措施的安全路线图（如工作流锁文件、策略控制等），但所有改进都是可选项，且默认配置短期内不会改变。

防护建议： 1. 使用zizmor等第三方扫描工具 2. 固定action的SHA引用而非标签 3. 在工作流顶部设置permissions: {} 4. 假设所有用户输入都可能成为shell脚本

现状反思： 当91%的PyPI软件包仍使用可变标签引用第三方action，三分之二工作流未设置权限限制时，仅靠可选的安全功能难以保护长尾项目。GitHub需要在破坏现有工作流和持续发生安全事件之间做出选择，特别是对公开仓库应采用更严格的安全默认值。

以下是评论内容的总结：

1. LLM在安全领域的潜力与风险

   • 观点：LLM能更快发现漏洞，但也加速了技术过时
   • 引用：
     "This should really what LLM ought to bring in terms of security... but we will in a adversarial world where the threat is constantly evolving."
     "Tomorrow (today) the servers and repo won't be scanned by scripts anymore but by increasingly capable models..."

2. 对GitHub Actions的批评

   • 观点：性能下降，Copilot集成仓促，可能迫使回归自托管方案
   • 引用：
     "Github actions is running like treacle now... people won't be able to ship and deploy code from Github actions."
     "We might dare I say it, have to go back to self hosted Jenkins or Travis CI."

3. 供应链安全建议

   • 观点：应使用commit hash而非标签来避免供应链攻击
   • 引用：
     "if you're not using a commit hash in your uses: lines, go switch to it now."
     "if you're just using major-version-only tags like v5 then do it RIGHT now"

4. 自托管解决方案的推崇

   • 观点：自托管实例简化流程，避免托管服务问题
   • 引用：
     "I just have a Spot instance we use for our builds... Lately i don't use any managed services and life couldn't be any simpler."

5. 对CI/CD平台的创新需求

   • 观点：需要开放、可编程的CI平台替代传统方案
   • 引用：
     "I've spent the last 5 years warning of the importance of not leaving CI locked in a black box platform"
     "consider checking out Dagger... a glimpse of what CI can be when you shed 30 years of legacy"

6. 安全工具的实践分享

   • 观点：开发运行时沙箱工具应对GHA安全缺陷
   • 引用：
     "started working myself on an open-source runtime sandbox for GHA... hasp enforces SHA pinning AND checks"
     "treating the runner as a zero-trust or actively malicious environment"

7. 替代工具推荐

   • 观点：推荐Ratchet等工具提升安全性，考虑迁移至Buildkite
   • 引用：
     "some tools we use that help... ratchet for pinning external Actions"
     "soon moving to Buildkite for orchestration of our CI jobs"

总结呈现了从技术革新、安全实践到平台迁移的多维度讨论，核心矛盾集中在托管服务的便利性与安全性/性能之间的权衡。