GitHub Actions Workflow Lockfiles Reach General Availability

GitHub 已于 2026 年 10 月 28 日正式推出 GitHub Actions 工作流依赖锁文件功能（正式版），该功能两周前刚进入公开预览阶段。

工作流可以保留清晰的标签和分支引用，运行器会执行 .github/workflows/actions.lock 文件中列出的代码提交，即便后续这些标签或分支引用发生变化也不会受影响。该功能支持 GitHub 企业云版、含数据驻留的企业云版、团队版以及免费版。正式版包含预览阶段的所有功能。

本次更新旨在解决 Actions 依赖解析长期存在的短板。类似 actions/checkout@v4 或是分支名这类引用可能会发生变化，这意味着如果某个 Action 被篡改，攻击者可以向流水线注入恶意代码，而无需修改使用该 Action 的代码库。团队虽然可以手动固定为完整的提交 SHA，但可读性会变差，而且无法固定传递依赖（如复合 Action 的依赖）。锁文件通过记录直接依赖和传递依赖的提交哈希同时解决了这两个问题。

相关工具通过 GitHub CLI 的 gh actions-lock 扩展提供，该扩展托管在 gh-actions-lock 代码库中，用于生成和维护锁文件。采用过程遵循一套工作流：工作流接入之后，所有依赖项都必须在锁文件中拥有对应的条目。Actions 运行时会执行记录的提交，无论标签或分支指向何处。团队可以进行逐步迁移，不必一次性转换整个组织。该扩展还提供了验证模式，可在不修改任何文件的情况下检查锁文件是否为最新状态，因此可以作为 CI 门禁，用于发现工作流文件与锁文件之间的差异。

Dependabot 集成解决了固定依赖带来的常见痛点——引用过期。当 Dependabot 为已接入工作流中的某个 Action 发起版本更新时，它会同时更新对应的锁文件条目。两项变更会出现在同一个拉取请求中，确保工作流引用与锁定的提交保持同步。GitHub 表示此功能无需额外配置即可使用。在治理方面，企业、组织和代码库管理员可以启用 “Require lockfile”（强制要求锁文件）策略，在对应范围内推动采用。

GitHub 明确说明了该机制的局限性：锁文件只能保证运行时使用你锁定的提交，但无法保证这些提交本身是安全的。公告建议在锁定依赖前对其进行审查。因此，该功能的安全价值取决于创建或更新条目时所做的审查工作。在实际使用中，Dependabot 的拉取请求成为了审查节点——如果团队对这些更新启用自动合并，恶意变更将直接写入锁文件。

本次发布之际，GitHub 正在收紧 Actions 的其他默认安全策略。11 月 2 日的更新公告提到，pull_request_target 将从 12 月 2 日起默认被阻止，同样是为了限制不受信任代码进入高权限工作流上下文。

正在评估是否采用该功能的团队可以查阅 GitHub 文档中关于工作流依赖锁文件的配置说明。推荐的思路：先接入少数高权限工作流（例如发布、部署流水线），在 CI 中加入过期校验，确认 Dependabot 的合并拉取请求符合现有审核流程后再启用企业级强制策略。

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

CircleCI 的 orb 使用中心化的语义化版本注册表而非提交哈希，该注册表具有不可变性。使用这些平台的团队通常会借助跨平台工具，例如使用 pinner 将标签固定到 SHA 并添加 CI 验证步骤，或依赖 ActionSieve 等扫描工具来标记未固定的引用。

这些工具可以固定流水线文件中写入的引用，但无法解析传递依赖，而这正是 GitHub 锁文件要解决的问题。与 GitHub 的这个功能一样，这些工具都无法判断被固定的依赖是否可信，因此锁定前的审查步骤仍然是真正起作用的安全控制点。

查看英文原文：https://www.infoq.com/news/2026/11/github-actions-lockfiles-ga/