如何防止被投毒的 GitHub Actions 依赖
内容提要
GitHub Actions 使用浮动标签（如 @v4）存在供应链风险，标签可被移动以执行恶意代码。建议将 Action 固定到完整提交 SHA，验证 SHA 与发布标签一致，设置允许列表限制可用 Action，启用 Dependabot 自动更新并人工审查，在 PR 检查中强制 SHA 固定，并审查第三方 Action 权限。
延伸解读
浮动标签的风险本质
文章指出，使用 @v4 这类浮动标签引用 GitHub Actions 时，标签可被维护者或攻击者移动到其他提交，导致工作流在不修改仓库的情况下执行恶意代码。这与未固定版本的应用依赖类似，属于供应链风险。固定到完整提交 SHA 可确保每次执行的都是经过审查的特定代码，避免标签移动带来的不确定性。
SHA 固定与验证的实操要点
固定 SHA 时需使用完整的 40 位字符，并添加注释标明可读版本以便维护。但固定后仍需验证 SHA 与发布标签是否一致，文章提供了验证脚本，通过 git ls-remote 比对标签指向的提交与记录的 SHA。验证通过仅代表引用一致，不代表代码可信，还需审查 Action 源码和权限。
自动化更新与人工审查的平衡
启用 Dependabot 可自动为固定的 SHA 提交更新 PR，但不应配置自动合并。每个更新 PR 都应人工审查，比较新旧提交、检查发布说明、审查 action.yml 和脚本变更，并确认新提交属于预期版本。对于涉及部署、发布或凭据的高影响操作，应在测试环境中验证后再合并。
分层防御：允许列表与 PR 检查
允许列表限制可用的 Action 发布者和仓库，减少引入未审查 Action 的风险，但不能替代 SHA 固定。在 PR 检查中强制 SHA 固定，可使用 actionlint 或简单 grep 检查浮动引用，但这类检查可能被绕过，需结合代码审查、允许列表和 SHA 验证流程。此外，应审查第三方 Action 的权限，遵循最小权限原则。
Q&A
为什么 GitHub Actions 中使用 @v4 这样的浮动标签存在安全风险？
浮动标签如 @v4 可以被移动到不同的提交，因此同一个标签可能执行不同的代码。如果维护者账户被入侵或攻击者控制了仓库，他们可以将标签指向恶意代码，而你的工作流会在没有修改仓库的情况下执行这些代码，从而带来供应链风险。
如何将 GitHub Actions 固定到完整的提交 SHA？
将 uses 引用中的分支或版本标签替换为完整的 40 位提交 SHA。例如，将 actions/checkout@v4 改为 actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2。可以在 Action 的 GitHub 发布页面找到 SHA，或使用命令 gh api repos/actions/checkout/git/ref/tags/v4.2.2 --jq '.object.sha' 获取。添加注释记录可读的版本号以便维护。
如何验证固定的 SHA 与发布的标签一致？
可以使用一个脚本比较标签背后的提交与工作流中记录的 SHA。脚本通过 git ls-remote 获取标签对应的提交 SHA，并与预期的 SHA 进行比对。如果不一致则报错退出。这确保你审查的发布标签与工作流中固定的提交一致。
如何为 GitHub Actions 配置 Dependabot 自动更新？
在 .github/dependabot.yml 中添加配置，指定 package-ecosystem 为 "github-actions"，设置目录和更新计划（如每周）。Dependabot 会检查工作流引用是否有新版本，并打开拉取请求更新它们。不要配置自动合并，应人工审查每个更新，比较新旧提交、检查发布说明和权限变更。
如何设置允许列表来限制可用的 GitHub Actions？
组织管理员可以在 Settings → Actions → Policies → Allow specified actions 中配置允许列表，只允许特定的 Action 仓库。例如添加 actions/checkout@*、actions/setup-node@* 等模式。对于单个仓库，可以在 Settings → Actions → General 中选择仅允许 GitHub 创建的操作，并限制为已验证的创建者。允许列表限制可运行的 Action 身份，但不能替代 SHA 固定。
如何在拉取请求中强制检查 Action 是否固定到 SHA？
可以在 CI 中运行工作流 linter（如 actionlint）并添加检查，当工作流引入非 SHA 引用时失败。例如使用 rhysd/actionlint 并固定其 SHA。还可以添加一个简单的 grep 检查来拒绝浮动标签引用。这些检查应在拉取请求和受保护分支上运行，但需结合代码审查、允许列表和 SHA 验证流程。
审查第三方 Action 时应该注意哪些方面？
在将社区 Action 加入允许列表前，应阅读其 action.yml 和入口脚本，检查星标历史、维护者声誉和未解决的安全问题。如果 Action 关键但由外部维护，应固定 SHA 并 fork 到内部组织。同时检查工作流权限，将顶层权限设为最小必要，仅按需为个别作业授予额外权限。
SHA 固定策略在哪些情况下可能失效或需要额外注意？
紧急补丁时 SHA 固定会减慢热修复速度，建议使用 Dependabot 加待命审查。私有仓库中的复合 Action 应像公共 Action 一样固定。可重用工作流需要将引用的工作流本身固定到 SHA。注解标签和镜像需要解析到提交后再记录 SHA，并通过内部变更控制流程验证。固定但不阅读代码仍会信任维护者，需结合允许列表、最小权限和审查。
