GitHub Actions推出工作流依赖锁文件正式版

GitHub于2026年10月28日正式推出Actions工作流依赖锁文件功能，此前该功能仅公开预览约两周。启用后，工作流仍可保留易读的标签或分支引用，但运行器会严格执行`.github/workflows/actions.lock`中记录的提交，即使相关标签或分支随后改变也不会影响执行。该功能覆盖企业云版、含数据驻留的企业云版、团队版和免费版。

这一机制主要用于弥补Actions依赖解析的安全缺口。类似`actions/checkout@v4`或分支名的引用可能被重新指向其他代码，攻击者因此有机会在不修改业务仓库的情况下向流水线注入恶意内容。手动改用完整提交SHA虽然能够提高稳定性，却会降低可读性，也无法覆盖复合Action依赖的其他Action。锁文件会同时记录直接依赖和传递依赖的提交哈希，从而解决这两个问题。

相关操作由GitHub CLI扩展`gh actions-lock`提供，该扩展托管在`gh-actions-lock`代码库中，可用于生成和维护锁文件。接入后，工作流中的每项依赖都需要在锁文件中拥有对应条目，运行时则以锁定提交为准。团队可以按工作流逐步迁移，不必一次性改造整个组织；扩展还提供只读验证模式，可在不修改文件的情况下检查锁文件是否过期，并作为CI门禁发现工作流与锁文件之间的差异。

Dependabot已支持同步更新锁文件。当它为已接入锁定机制的Action创建版本升级拉取请求时，会同时修改相应的锁文件条目，使引用版本和实际锁定提交在同一个拉取请求中保持一致，无需额外配置。企业、组织和仓库管理员还可以启用“Require lockfile”策略，在指定范围内强制要求使用锁文件。

GitHub同时强调，锁文件只能确保运行时使用指定提交，不能证明该提交本身安全。因此，依赖在首次锁定或更新前仍需人工审查；若团队对Dependabot拉取请求启用自动合并，恶意代码可能未经充分检查就被写入锁文件。GitHub近期也在收紧其他默认安全策略，例如宣布从12月2日起默认阻止`pull_request_target`，以减少不受信任代码进入高权限工作流上下文的机会。

实际部署时，可以先从发布和部署等高权限工作流开始，在CI中加入过期检查，并确认Dependabot更新符合现有审核流程，再扩大范围并启用企业级强制策略。其他平台目前尚未公布同等的原生传递依赖锁定能力：GitLab主要建议将include、组件和镜像固定到SHA或摘要，并在2026年3月供应链安全事件后推出侧重拦截已知攻击模式的开源流水线执行策略；Azure Pipelines也建议使用SHA并限制Marketplace扩展；CircleCI则依赖具备不可变性的语义化版本Orb注册表。跨平台工具如pinner和ActionSieve可以固定引用或扫描未固定项，但通常无法解析传递依赖，且同样不能替代锁定前的安全审查。