理解 Composer GitHub Action 中的 GitHub_TOKEN 泄露问题

持续集成 (CI) 流水的安全性通常是组织的一个关键漏洞点。最近的一份安全公告 (GHSA-f9f8-rm49-7jv2) 引起了人们对一个特定实例的关注，即 GITHUB_TOKEN 在 GitHub Action 的日志中被无意中泄露了。这一事件是一个重要的提醒，说明了敏感凭据如何轻易地通过日志机制泄露，以及验证第三方 Action 的重要性。

泄露的本质

与最初报告和标题暗示 GitHub Actions 本身存在系统性故障不同，该漏洞并非 GitHub 平台核心基础设施的缺陷。相反，问题存在于 Composer 项目（PHP 的依赖管理器）提供的特定 GitHub Action 中。

当工作流使用 GITHUB_TOKEN 进行身份验证时，GitHub Actions 通常会通过将这些密钥替换为星号来在日志中掩盖这些密钥。然而，如果一个 Action 执行的操作修改或验证了同一个 token，且其方式使得平台的掩盖机制无法识别，那么该 token 就会以明文形式打印到 stdout/stderr 日志中。

技术影响与风险

对于在 GitHub Actions 工作流中使用 Composer 的组织而言，风险在于任何有权访问这些工作流日志文件的人或实体都可以获取活跃的 GITHUB_TOKEN。

虽然 GITHUB_TOKEN 通常是短寿命的，并且其作用域仅限于特定的存储库，但其泄露可能允许攻击者以该 token 被分配的相同权限执行操作。根据工作流权限的配置，这可能从只读访问权限扩展到推送代码或创建发布版本的能力。

社区讨论与反驳观点

围绕该事件的技术讨论强调了关于 CI/CD 工具安全态势的几个关键点：

密钥掩盖失败

用户提出的主要担忧之一是 token 泄露的原因。一位贡献者指出，验证不透明身份验证密钥的结构——而不是简单地访问像 /rate_limit 这样无害的端点来验证 token 的有效性——是一种危险的做法，这往往会导致意外的泄露。

DevOps 复杂性

一些从业者对 GitHub Actions 生态系统表达了挫败感，认为该平台的设计初衷是易于初始设置，但在“严肃的 DevOps”实践中缺乏所需的深度。这种情绪表明，该平台对简单集成而非严格安全默认设置的依赖可能会为开发者带来陷阱。

缓解措施与建议

为了保护您组织的流水线，建议采取以下步骤：

  1. 审计 Composer Actions：如果您在 GitHub Actions 中使用 Composer，请确保您使用的是已修复此泄露问题的最新版本 Composer Action。
  2. 验证密钥掩盖：不要仅仅依赖平台的内置掩盖机制。确保您的自定义脚本或第三方 Action 不会将包含密钥的环境变量显式地打印到日志中。
  3. 最小权限原则：将您的 GITHUB_TOKEN 权限配置为尽可能严格。GitHub 现在默认鼓励使用 GITHUB_TOKEN 的只读权限，以限制潜在泄露的影响范围。
  4. 立即行动：正如漏洞报告者所建议的，如果您不确定您的 Action 正在运行哪个版本的 Composer，请考虑在更新之前禁用受影响的工作流。

Sources