VibeGuardLive feed
APIMCPRSSSkill查询
返回首页查看原文

AWS GitHub Action 中可疑的标签移动：事件始末及其重要性

AWS 发布回滚如何触发了与供应链攻击相同的危险信号——以及为何将每次标签移动视为可疑行为是保护 CI/CD 流水线的关键

2025 年 8 月 4 日，AWS 热门 GitHub Action 仓库 aws-actions/configure-aws-credentials 发生了一个异常事件：发布标签 v4.3.0 被创建、删除（取消发布），然后在当天晚些时候被重新创建并指向一个不同的提交。

换句话说，这个标签"移动"了。对于资深安全工程师来说，移动的标签是极其罕见的，而且通常是一个危险信号。Git 标签——尤其是语义版本发布的版本标签——通常被视为不可变引用。当已发布的标签被更改或重新标记到新的提交时，可能表明出了问题，甚至可能是供应链被攻击。

在这种情况下，StepSecurity 的自动化监控系统立即将此事件标记为可疑。

AWS 仓库是否被黑客入侵了？攻击者是否悄无声息地替换了 4.3.0 版本背后的代码？事实证明，真相更加无害：AWS 团队"取消发布"了一个有问题的更新，然后进行了修复。但这一事件提供了一个宝贵的教训。​即使是良性的发布也可能触发与恶意攻击相同的指标，这凸显了为什么标签移动值得密切关注。

事件经过：标签 v4.3.0 的创建、取消发布和重新创建

configure-aws-credentials action——一个被超过 225,000 个仓库使用的热门 GitHub Action——在 2025 年 8 月 4 日经历了一个多事之秋。以下是导致标签被移动（重新指向）到新提交的关键事件时间线：

  • 初始发布（17:49 UTC）：​ v4.3.0 标签首次由自动化发布工作流创建，指向提交 59b44184。这标志着该 action 4.3.0 版本的正式发布。

  • 发现 Bug（18:16 UTC）：​ 几分钟后，有人报告了一个严重 Bug——新的 v4.3.0 版本破坏了 action 的代理支持。这意味着使用 v4.3.0 的任何人都将遇到代理功能故障。

  • 标签"取消发布"（约 18:34 UTC）：​ AWS 维护者决定撤回有问题的发布。v4.3.0 标签被删除（实际上，使 v4.2.1 再次成为最新可用版本）。这是一个不寻常的步骤，由于 Bug 的严重性，本质上是"取消发布"一个发布标签。

  • 修复和更改（18:34–20:34 UTC）：​ 团队紧急修补问题。多个提交进入仓库以恢复有问题的更改并为代理 Bug 应用了适当的修复。这些包括恢复之前的 PR 并更新代码以正确设置代理环境变量。

  • 强制重新发布（20:34 UTC）：​ 第二次发布工作流启动以发布更正后的 v4.3.0。维护者在提交消息中包含了 Release-As: 4.3.0 指令，指示发布自动化（Release Please）​重用版本号 4.3.0，而不是递增到新版本。这是必要的，因为原来的 4.3.0 已被"取消发布"，他们希望在修复后重新发布相同版本。

  • 标签重新创建（20:47 UTC）：​ 修复合并后（具体是 PR #1419 的合并提交 d0834ad），发布自动化重新创建了 v4.3.0 标签——这次指向新的修复提交而不是原来有问题的提交。在构建日志中，Release Please 注明它正在"为 pull #1419 创建 1 个发布"，表明标签被标记到了新代码。

本质上，标签在几个小时内从提交 59b44184 移动到了提交 d0834ad。

第一个标签位置：​ 59b44184（创建于 17:49:16Z，原始发布提交）

最终标签位置：​ d0834ad（创建于 20:47:54Z，修复之后——标签被移动到了此提交）

这种标签变动在正常发布实践中是非常不典型的。让我们探讨为什么这引起了安全方面的关注。

为何标签移动是罕见的危险信号以及它们何时具有恶意

在典型的开发工作流中，一旦语义发布标签被推送——特别是已经分发给用户的标签——它应该保持固定。移动标签到新提交，或删除并重用它，是罕见的，因为它可能会混淆下游用户和自动化。从安全角度来看，这更加令人担忧，因为它可能表明攻击者在事后修改了发布，将版本指向恶意代码。标签篡改是软件供应链攻击中众所周知的策略，即使原因是合法的，在调查之前，这种模式与潜在的攻击是无法区分的。

这就是为什么在安全实践中，移动的标签被视为"有罪直到证明无罪"。历史表明这种谨慎是合理的，因为生态系统已经看到了真实的案例，其中标签移动不是无害的意外，而是有意的攻击。

来自 tj-actions 和 reviewdog 的教训

2025 年 3 月发生的两个 notable 事件说明了恶意标签篡改如何影响数千个项目：

  • [tj-actions/changed-files 妥协（2025 年 3 月）：​ 攻击者获得了广泛使用的 GitHub Action（tj-actions/changed-files）仓库的写访问权。然后他们更新了多个版本标签以引用恶意提交。实际上，所有现有的带标签版本（例如 v34、v35 等）都被静默地重新指向恶意软件。这个恶意提交运行了一个 Python 脚本，转储了 runner 中的 CI/CD 密钥，并在构建日志中暴露了它们。​StepSecurity Harden Runner 在妥协发生三小时内检测到了标签篡改，触发调查以防止攻击进一步传播。尽管如此，操纵仍然影响了信任该 Action 的一些仓库，导致许多 CI 管道中的密钥被泄露。GitHub 后来删除了该 action 和所有恶意标签，并为此事件分配了一个 CVE。

  • [reviewdog/action-setup 妥协（2025 年 3 月）：​ 在一次相关攻击中，reviewdog/action-setup action 的 v1 标签被短暂指向一个包含 base64 编码有效载荷的恶意提交，旨在窃取密钥。reviewdog actions 被用作许多其他 composite actions 的依赖项，因此这一个标签更改可能危及 reviewdog 生态系统中多个 actions。当 v1 标签被劫持的窗口期（约 2025 年 3 月 11 日 18:42–20:31 UTC）期间，任何拉取 reviewdog/action-setup@v1 的工作流实际上都会运行漏洞代码。这个隐蔽的标签移动后来被安全研究人员发现并由维护者确认。它展示了攻击者如何通过重新标记现有语义标签的细微操作对许多项目产生级联效应。

这些事件证明移动的标签不仅仅是一个好奇心——它是一种已知的攻击向量。虽然 AWS v4.3.0 案例是无害的，但它遵循了与这些恶意妥协完全相同的模式，这就是为什么它触发了立即调查。

StepSecurity Artifact Monitor 的自动检测

此标签更改被 StepSecurity 的 Artifact Monitor 自动捕获。StepSecurity 的 Artifact Monitor 持续监控软件发布（标签、软件包等）是否有被篡改或异常行为的迹象。在这种场景中，监控器标记了" aws-actions/configure-aws-credentials@v4.3.0 "发布，因为该标签的历史偏离了正常模式。

StepSecurity Artifact Monitor 如何检测到它？

我们每几分钟监控超过 3,000 个流行 GitHub Actions 的新标签/现有标签更新。如果现有语义标签已更改指向新提交，StepSecurity Artifact Monitor 会触发检测警报。

通过在几分钟内捕获标签移动，StepSecurity 的 Artifact Monitor 使调查能够立即开始。在恶意场景中，这种早期检测可能是控制事件和广泛传播之间的区别。在 AWS 案例中，监控器的警报导致验证了更改的细节，幸运的是，这与维护者关于发布失败的公开解释一致。

Artifact Monitor 的其他检测

StepSecurity 的 Artifact Monitor 也检测到了其他流行 GitHub Actions 中类似的标签移动事件。

Cache Extension

Firebase Action

在这两个案例中，标签更改都不是恶意的，但它们可能是。

如果此类更改被确认为恶意的，StepSecurity 会将该 Action 标记为已妥协 Action。

已妥协 Actions 策略

当 StepSecurity 识别出已妥协 Action 时，它会被添加到我们的内部已妥协 Actions 列表中。在其组织中启用了已妥协 Actions 工作流策略的客户会自动受到保护，防止在工作流中使用已妥协 Action。

您可以了解更多关于已妥协 Actions 工作流运行策略的信息。

探索这个交互式演示，了解已妥协 Actions 策略如何工作：

结论：监控您的发布并在威胁之前保持领先

AWS v4.3.0 标签事件原来是发布过程中的无害错误，但它作为供应链安全的宝贵演练。通过展示我们的工具和流程——在这种情况下是 StepSecurity 的 Artifact Monitor——按预期工作，在实时捕获异常。它表明，即使这是一个恶意的重新标记，早期检测也可以挽救无数下游用户免受暴露。

对于安全工程师来说，结论是明确的：

  • 将意外的标签更改视为紧急事件：​ 它们可能是像热修复标签重新创建这样的罕见事件，但也可能是入侵的第一个迹象。快速调查总是更安全的。
  • 投资于自动化发布监控：​ 就像我们监控代码更改和部署一样，我们应该监控我们的工件发布和版本标签。在复杂的 CI/CD 生态系统中，手动监督是不够的。像 StepSecurity Artifact Monitor 这样的工具可以自动将每个新发布与您的预期构建管道进行比较，并在异常时发出警报（如不是由正常流程创建的标签，或移动的标签）。
  • 从过去的攻击中学习：​ tj-actions 和 reviewdog 案例中的标签篡改只有在密钥被盗后才被捕获。这些事件促使社区中的许多人收紧控制（例如，将 actions 固定到不可变的 commit SHA 哈希而不是浮动的版本标签）。主动监控标签和发布增加了另一层防御，以更快地捕获类似问题。

最终，目标是确保当下一次"奇怪的标签移动"发生时——迟早会发生——您的团队不会措手不及。无论这是无意的错误还是在进行的攻击，您都已准备好快速响应并保护您的软件供应链。

StepSecurity 的 Artifact Monitor，可在我们的企业版中使用，提供对关键 GitHub Actions 和其他发布工件的持续、自动监控——在几分钟内检测可疑的标签更改，并在您的环境中运行已妥协 Actions 之前阻止它们。

下一次攻击不会等待！！

立即开始您的企业版试用，确保您拥有在攻击传播之前阻止它所需的可见性和保护。