GitHub Actions 锁文件正式可用：把流水线依赖钉死在提交哈希上

CI/CD 流水线是现代软件里权限最大的地方之一：它能读代码、拿密钥、推镜像、发版本。而它依赖的第三方 Action，过去大多靠一个可变的标签引用，比如 v4。

标签可以被改指向，分支可以被强推。攻击者只要拿到某个 Action 仓库的写权限，就能在不改动你仓库一行代码的情况下，把恶意逻辑注入你的流水线。GitHub 现在给出的答案，是一份锁文件。

一分钟速览

• GitHub 于 2026 年 10 月 28 日正式发布 Actions 工作流依赖锁文件功能，此前两周进入预览。
• 锁文件位于 .github/workflows/actions.lock，同时固定直接依赖与复合 Action 的传递依赖的提交哈希。
• 运行时严格按锁文件记录的提交执行，无视标签或分支当前指向何处。
• 由 gh actions-lock CLI 扩展驱动，支持生成、校验与渐进式迁移；校验模式可作为 CI 门禁。
• Dependabot 会在同一个 PR 中同步更新锁文件；企业、组织、仓库管理员可启用“Require lockfile”策略。

问题出在哪：标签是可变引用

在 Actions 工作流里引用第三方 Action，常见写法是指向 v3、v4 这类标签，或者干脆指向主分支。这两类引用都可能变化。团队当然可以手动把引用固定成完整提交 SHA，安全性上去了，可读性掉下来，而且有个更隐蔽的缺口：复合 Action 的传递依赖根本固定不住。

锁文件同时解决这两件事：它把直接依赖和传递依赖的提交哈希一起记下来，工作流文件依然保持可读的标签写法，实际执行时以锁文件为准。

落地方式：先小范围接，再谈强制

采用流程是一套明确的工作流：接入之后，所有依赖项必须在锁文件里有对应条目；运行时不看标签指向，只执行记录的提交。团队可以分批迁移，不必一次性转换整个组织。

gh actions-lock 扩展提供的校验模式值得单独说：它不修改任何文件，只检查锁文件是否与工作流保持一致，因此天然适合放进 CI 当门禁，用来发现工作流与锁文件之间的漂移。

Dependabot 的集成解决了固定依赖最常见的痛点——引用过期。当它为某个 Action 发起版本更新时，会把锁文件条目一并更新，两项变更出现在同一个拉取请求里。GitHub 表示这一步不需要额外配置。

它挡不住什么

GitHub 在公告里说得很清楚：锁文件只能保证运行时使用你锁定的提交，无法保证这些提交本身是安全的。锁定之前有没有审查，才是真正的安全控制点。

这个限制定全了整个流程的关键节点：Dependabot 的 PR。如果团队对这些更新启用了自动合并，恶意变更就会顺着自动合并直接写进锁文件，锁文件反而变成了一条更顺滑的通道。换句话说，锁文件把“信任决策”从运行时前移到了合并时，责任也更明确了。

横向看：各家都在补同一块短板

GitLab 在 2026 年 3 月的供应链安全事件之后引入了更严格的固定机制，建议用户把 include 与组件固定到提交 SHA、镜像固定到摘要值。CircleCI 的 orb 走的是另一条路：中心化的语义化版本注册表，靠注册表的不可变性保证引用稳定。

跨平台工具也能固定流水线文件里的引用，但普遍无法解析传递依赖，而这恰好是 GitHub 锁文件要补的洞。共同点是，没有任何工具能替你判断被固定的依赖是否可信。

给团队的一份落地建议

比较稳妥的顺序是：先挑少数高权限工作流接入，比如发布、部署、制品签名这类流水线；接着在 CI 里加上锁文件校验，让漂移在合并前暴露；确认 Dependabot 的合并 PR 走的是现有审核流程之后，再考虑在组织或企业层面启用强制策略。

供应链安全没有一次性方案。锁文件把可变引用变成不可变提交，是把攻击面收窄了一步，但最后那道人工审查，仍然得有人认真看。