文章指出GitHub Actions的依赖管理存在严重缺陷，缺乏锁文件、完整性校验等基本安全功能，远落后于npm等成熟包管理器，可能成为软件供应链安全的薄弱环节。

标题：GitHub Actions的包管理器可能是最糟糕的

在研究了GitHub Actions的依赖解析机制后，我发现其包管理功能存在严重缺陷。与其他成熟的包生态系统相比，GitHub Actions缺少多项关键安全功能：

核心问题： 1. 缺少锁定文件（lockfile），导致每次运行都可能重新解析依赖版本 2. 版本可变性：即使使用标签（如@v4），维护者仍可推送新提交并重新标记 3. 无法查看或控制传递依赖 4. 缺少完整性验证机制 5. 重新运行无法保证一致性

安全风险： - 研究表明99.7%的仓库执行外部开发的Actions - 97%使用未经验证创建者的Actions - 18%运行存在安全更新的Actions - 静态污点分析发现270万个工作流中存在4300多个代码注入漏洞

与其他包管理器的对比：

| 功能 | npm等成熟系统 | GitHub Actions | |------------|-------------|---------------| | 锁定文件 | ✓ | ✗ | | 传递依赖固定 | ✓ | ✗ | | 完整性哈希 | ✓ | ✗ | | 依赖树可视化 | ✓ | ✗ | | 解析规范 | ✓ | ✗ |

其他问题： - 没有中央注册表 - 共享可变环境 - 不支持离线运行 - 命名空间基于GitHub用户名，易受账户劫持攻击

解决方案建议： 1. 引入锁定文件记录所有依赖的SHA 2. 添加完整性哈希验证 3. 提供依赖树检查功能

尽管GitHub已添加部分缓解措施（如不可变发布、强制SHA固定等），但这些仅解决顶层依赖问题，对传递依赖这一主要攻击媒介无效。

背景： GitHub Actions的设计源于Azure DevOps，最初面向企业内部可信任务库。GitHub在此基础上添加公共市场时未重新考虑信任模型，导致当前的安全缺陷。

影响范围： 这些问题不仅影响GitHub用户，也波及兼容GitHub Actions的其他平台（如Forgejo）。随着越来越多的软件注册表使用GitHub Actions进行可信发布，其安全问题的影响正在扩大。

（注：本文保留了原文的核心技术分析和安全警示，删减了部分代码细节和重复的示例说明，同时优化了中文表达方式。）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

1. GitHub Actions的维护与安全问题

• 观点：GitHub Actions维护不足，依赖第三方存在安全隐患
• 论据：
  • "GitHub has basically stopped maintaining their own actions... held up with duct tape" (评论1)
  • "A quick malicious push can exfiltrate data from repositories" (评论2)

2. CI/CD系统设计争议

• 观点：CI/CD系统应避免直接处理密钥
• 论据：
  • "a good CI/CD system should not support secrets as a first-class object" (评论3)
  • 应通过安全隔离区处理API权限，而非直接暴露密钥

3. 替代方案讨论

• 支持Docker方案：

  • "using regular utilities inside Docker containers... faster & no vendor lock-in" (评论4)
  • 但存在文档不足问题："how do you get credentials... most docs just say use this Action" (评论4)

• 反对YAML配置：

  • "Why not use a decent programming language instead of YAML" (评论12)

4. 版本控制与锁定机制

• 现有问题：

  • "results can change without any code modification" (评论11)
  • 存在随机错误："GHA errors disappear after few days without changes" (评论11)

• 解决方案争议：

  • 支持SHA锁定："using commit SHA is safest" (评论10)
  • 但仍有局限："doesn't work for transitive dependencies" (评论10)

5. 行业标准批评

• 观点：GitHub Actions成为行业标准是问题
• 论据：
  • "embodiment of everything bad in 'less is more'" (评论5)
  • 导致工程师缺乏对比："young engineers don't know how short their stick is" (评论5)

6. 迁移决策反思

• 观点：坚持传统CI工具可能更优
• 论据：
  • "vindicated in pushing back on migrating from Jenkins" (评论9)
  • 维护成本考虑："this will be a lot of work argument won" (评论9)

7. 安全工具建议

• 推荐方案：
  • "Zizmor for static analysis, Harden Runner for security" (评论14)
  • 期待SLSA规范："Hermetic build process as requirement" (评论14)

关键矛盾集中在：便利性vs安全性、厂商锁定vs灵活性、YAML配置vs编程语言等方面。多数批评指向GitHub Actions的设计缺陷，但也有评论指出文档已包含部分解决方案（如SHA锁定）。