GitHub Actions锁文件功能转正：工作流依赖可锁定提交

GitHub Actions 的工作流依赖锁文件功能，2026 年 10 月 28 日已转为正式版。两周前，它才刚进入公开预览阶段。

工作流仍可保留易读的标签和分支引用，真正执行时，运行器会按.github/workflows/actions.lock所记录的提交来跑，哪怕之后标签或分支引用被改动，也不受影响。企业云版、带数据驻留的企业云版、团队版和免费版都能用。预览阶段的功能，正式版全部保留。

这次更新针对的是 Actions 依赖解析长期没解决的老问题。像actions/checkout@v4或者分支名这样的引用会变。一旦某个 Action 被篡改，攻击者不用改调用方代码库，就能把恶意代码塞进流水线。团队当然可以手动固定到完整提交 SHA，但可读性会下降，传递依赖（比如复合 Action 的依赖）也固定不了。锁文件把直接依赖和传递依赖的提交哈希都记下来，两个问题一起解决。

配套工具以 GitHub CLI 的gh actions-lock扩展形式提供，托管在 gh-actions-lock 代码库，用来生成和维护锁文件。接入流程是这么走的：工作流接入之后，每个依赖项都得在锁文件里有对应条目。运行时执行的是记录下来的提交，不管标签或分支现在指向哪里。团队可以一步步迁移，不用一次性把整个组织都转过来。这个扩展还有验证模式，不改任何文件就能检查锁文件是否最新，可以当作 CI 门禁，用来发现工作流文件和锁文件之间的差异。

Dependabot 集成解决的是固定依赖后的常见麻烦：引用过期。Dependabot 为已接入工作流里的某个 Action 发起版本更新时，会顺带更新锁文件里的对应条目。两项改动落在同一个拉取请求里，工作流引用和锁定的提交就能保持同步。GitHub 表示这项功能不用额外配置。治理层面，企业、组织和代码库管理员可以打开 “Require lockfile”（强制要求锁文件）策略，在各自范围内推动采用。

GitHub 也把局限说清楚了：锁文件只能保证运行时用的是你锁定的提交，这些提交本身安不安全，它保证不了。公告建议锁定依赖之前先做审查。说到底，这个功能的安全价值，取决于创建或更新条目时审查做得怎么样。实际使用中，Dependabot 的拉取请求就成了审查节点——要是团队对这些更新开了自动合并，恶意变更会直接写进锁文件。

发布这个功能的同时，GitHub 还在收紧 Actions 的其他默认安全策略。11 月 2 日的更新公告提到，从 12 月 2 日起 pull_request_target 默认会被阻止，目的同样是限制不受信任的代码进入高权限工作流上下文。

正在评估要不要用的团队，可以去查 GitHub 文档里工作流依赖锁文件的配置说明。建议的路径是：先接入少数高权限工作流（比如发布、部署流水线），在 CI 里加过期校验，确认 Dependabot 的合并拉取请求符合现有审核流程，再启用企业级强制策略。

截至现在，其他同类平台都还没宣布类似的原生功能。GitLab 的流水线安全指南建议用户手动把 include 和组件固定到提交 SHA，镜像固定为摘要值。2026 年 3 月的供应链安全事件之后，GitLab 推出了开源流水线执行策略，但这些策略重点在拦截已知攻击模式，不是生成依赖清单。微软 Azure Pipelines 的零信任指南同样建议用 SHA 固定，并建议限制 Marketplace 扩展的使用。

CircleCI 的 orb 用的是中心化的语义化版本注册表，不是提交哈希，这个注册表本身不可变。用这些平台的团队，通常会借助跨平台工具，比如用 pinner 把标签固定到 SHA 并加 CI 验证步骤，或者靠 ActionSieve 这类扫描工具标出未固定的引用。

这些工具能固定流水线文件里写下的引用，但解析不了传递依赖，而这恰恰是 GitHub 锁文件要解决的问题。和 GitHub 这个功能一样，它们都判断不了被固定的依赖可不可信，所以锁定前的审查环节，仍然是真正起作用的安全控制点。