在现代软件开发中，持续集成与持续部署（CI/CD）已成为基础设施的核心组成部分。GitHub Actions 作为最受欢迎的 CI/CD 平台之一，为数百万开发者提供了自动化工作流的能力。然而，这种便利性也带来了严峻的安全挑战。2025 年披露的 CVE-2025-30066 供应链攻击事件彻底暴露了 GitHub Actions 在供应链安全层面的系统性缺陷，使得这一平台成为攻击者眼中的「最薄弱环节」。本文将从漏洞根因、攻击面分析与可落地防护参数三个维度，深入剖析 GitHub Actions 的安全脆弱性。
工作流权限过度宽松：默认配置的风险根源
GitHub Actions 默认赋予工作流令牌（token）相当宽泛的权限，这是供应链安全的第一道裂痕。当开发者创建新的工作流文件时，系统并不强制要求显式声明权限范围，导致许多工作流在默认情况下拥有对仓库内容的读写权限，甚至可以访问敏感 secrets。根据行业安全研究，大多数 GitHub Actions 工作流请求了超出其实际需求的权限范围，这种过度授权的做法为攻击者提供了广阔的横向移动空间。
工作流令牌的权限包括但不限于 contents（仓库内容）、secrets（敏感信息）、pull-requests（拉取请求）以及 write 级别的操作权限。当某个工作流步骤被攻破时，攻击者可以利用这些宽泛的权限执行未授权的操作，例如篡改代码仓库、窃取敏感凭证或触发恶意部署。更为严重的是，许多组织并未对工作流权限进行细粒度的控制，导致单一工作流的沦陷可能波及整个软件供应链。
在实际工程实践中，建议在每个工作流文件的顶层显式声明最小权限集合。例如，仅需要进行代码测试的工作流应当将 contents 权限限制为 read，secrets 权限设为 none，pull-requests 权限设为 read。只有在确有必要的情况下，才为特定作业（job）授予更高的权限。这种权限最小化原则能够显著降低攻击成功后的影响范围。
Secrets 泄露：日志与输出中的隐形威胁
GitHub Actions 中的 secrets 管理是另一个频繁出现问题的领域。虽然平台提供了内置的 secrets 加密存储机制，但开发者在使用过程中往往忽视了 secrets 在日志和输出中泄露的风险。当工作流步骤将变量或敏感信息输出到标准输出时，这些内容可能被完整记录在构建日志中，即使 secrets 已被标记为加密，错误配置的日志记录仍可能导致敏感信息暴露。
常见的 secrets 泄露场景包括：在步骤中直接使用 echo 输出包含 secrets 的环境变量、在第三方 action 的参数中传递未经掩码的敏感值、以及在错误信息中意外暴露凭证内容。攻击者可以通过访问公开的构建日志获取这些泄露的 secrets，进而对供应链造成进一步破坏。2025 年的供应链攻击事件中，攻击者正是利用了 secrets 在日志中的意外暴露，实现了对数千个仓库的横向渗透。
针对 secrets 泄露问题，组织应当采取多层防护策略。首先，在所有可能输出敏感信息的步骤中强制使用 GitHub 提供的秘密掩码机制，确保日志中不会明文显示 secrets 内容。其次，限制工作流日志的可见性范围，仅允许必要的团队成员访问构建记录。第三，定期审计历史日志，检测是否存在 secrets 意外暴露的情况。最后，建立 secrets 轮换机制，即使发生泄露也能将损失降到最低。
第三方 action 投毒：供应链攻击的核心向量
第三方 action 的安全风险是 GitHub Actions 供应链中最具破坏性的攻击面。开发者通常会从 GitHub Marketplace 或其他公开仓库引入各类 action，以实现代码 lint、依赖更新、容器构建等功能。然而，这些第三方 action 的代码并未经过严格的安全审计，开发者往往对其内部实现一无所知，这就为投毒攻击提供了可乘之机。
CVE-2025-30066 事件充分说明了这一风险的严重性。攻击者成功侵入了广泛使用的 tj-actions/changed-files action，并在其中植入了恶意代码。该恶意代码能够窃取工作流执行过程中的敏感信息，包括访问令牌和其他凭证。由于该 action 被数千个仓库依赖，攻击范围迅速扩大，引发了包括 CISA 在内的多家安全机构的紧急警告。这一事件暴露出 GitHub Actions 生态在供应链安全审核机制上的系统性缺失。
防护第三方 action 投毒需要采取多层次的策略。首先，严格限制可使用的 action 来源，优先选择 GitHub 官方维护的 action 或经过安全审计的知名维护者。其次，永远不要使用未固定版本的 action，而应当将 action 版本锁定到特定的完整 SHA 哈希值，以防止版本劫持攻击。第三，定期监控所使用 action 的安全公告，及时更新到 patched 版本。第四，考虑将关键的重复性操作封装为内部 action，减少对外部代码的依赖。第五，部署专门的安全工具持续监控供应链依赖的安全状态。
可落地的安全加固参数清单
基于上述分析，组织应当建立系统化的 GitHub Actions 安全加固方案。以下是经过验证的关键配置参数，可直接应用于工作流文件中。
在工作流权限配置方面，建议采用以下最小权限模式：在 workflow 级别设置 permissions 为空对象或仅保留必要权限，然后在需要更高权限的特定 job 中使用 jobs.<job_id>.permissions 进行细粒度控制。例如，持续集成作业应仅授予 contents: read 和 statuses: write，而部署作业应仅在确认环境隔离到位后授予 contents: write 和 secrets: read。
在 action 管理方面，应当强制要求所有第三方 action 使用完整的 SHA 引用而非版本标签。例如，不使用 actions/checkout@v4，而使用 actions/checkout@a81bbbf8298c0fa03ea29cdc473d45769f953675。同时，建立内部 action 版本库，对所有引入的外部 action 进行安全评估并记录版本映射关系。
在 secrets 管理方面，应当启用 GitHub 的 secret scanning 功能，并在工作流中强制执行以下规则：任何可能包含 secrets 的环境变量必须通过 steps.env 声明为 secret，任何第三方 action 的敏感参数必须使用 ${{secrets.VAR_NAME}} 语法引用，构建日志保留期限不应超过 30 天。
在监控与响应方面，建议集成 GitHub 提供的安全 advisory 和 Dependabot 警报，对涉及工作流安全的漏洞实现自动告警。同时，建立针对异常工作流行为的检测机制，例如在同一作业中频繁调用 secrets 访问或尝试访问非预期资源的情况。
结语
GitHub Actions 供应链安全缺陷的本质在于设计理念与实际使用之间的巨大落差。平台在追求开发便利性的同时，未能充分考虑到企业级安全需求；开发者在享受自动化红利的同时，往往忽视了潜在的风险敞口。CVE-2025-30066 事件不是孤例，而是对整个生态系统的警示。只有通过系统化的权限控制、严格的 action 供应链管理以及完善的 secrets 保护机制，才能将 GitHub Actions 从供应链的「最薄弱环节」转变为真正可靠的安全基座。
资料来源：本文关于 CVE-2025-30066 供应链攻击事件的细节参考自 FortiGuard Labs 威胁报告及 CISA 安全公告。