Michael Johnson如果 workflow 引用的是类似 @v3 的标签，我们能信任 GitHub Actions 吗？锁文件会明确指定实际执行的 action commit，即使标签之后被移动也是如此。团队可以在 diff 中审查依赖更新，并维护 CI 所用 actions 的可审计清单。需要注意的是：锁文件涵盖由步骤调用的 actions；在 job 级别调用的可复用工作流则需要单独固定。本文所述机制适用于 GitHub Enterprise Cloud。
锁文件究竟固定了什么？
分支和标签引用十分方便，但它们指向的版本可能会变。像 uses: octo-org/deploy-action@v3 这样的记录指向一个标签名称；GitHub 会在运行时将其解析为 commit。如果项目所有者移动了该标签，那么在未固定依赖的情况下，下次运行可能会获取不同的代码。
根据GitHub 关于锁文件的文档，文件 .github/workflows/actions.lock 会存储依赖引用及对应的 commit SHA，其中也包括传递依赖——也就是其他 actions 所使用的 actions。该文件由 GitHub CLI 扩展 gh actions-lock 创建，不应手动编辑。
生成器还可以细化 workflow 文件中的 uses 引用：例如，将浮动标签的引用改得更具体，同时保留创建锁文件时该引用所解析到的 commit。因此，采用这一机制时，应审查完整 diff——包括 workflow 和锁文件的更改——并确认固定的版本确实是团队计划运行的版本。
此后，依赖更新会成为仓库中可见的变更：团队可以检查 commit 的变化、讨论更新，并通过常规代码审查予以接受。锁文件有助于审计 actions 代码并保持依赖一致；但它本身并不能证明所选代码是安全的。
固定范围在哪里结束？
在 jobs.<job_id>.uses 中调用的可复用工作流，不会由调用方仓库的锁文件固定。可复用工作流的依赖属于定义该工作流的仓库。若要固定工作流调用本身，请指定完整的 commit SHA；若要固定其中的 actions，则需在源仓库中使用自己的锁文件。
锁文件管控的是 actions 代码，而不是其他构建输入，例如传递给 action 的参数、机密信息或 runner 镜像。它回答的是一个具体问题：将执行哪个 commit 的 action 代码？其余元素需要各自的管理规则。
还有一种特殊情况：通过类似 uses: ./ 的路径调用本地 action。根据 GitHub 的说明，gh actions-lock 扩展不会固定或分析本地 action 路径。如果这类 action 使用其他 actions，就需要单独管理相关依赖；文档还介绍了将本地 action 引用迁移为 $/ 格式的做法。
因此，单条锁文件记录可能只是依赖链的一环，并不能取代对链上所有环节的管控。对于外部可复用工作流，请检查调用是否已固定以及源仓库的状态；对于本地 actions，请检查其依赖究竟如何纳入管理。
如何在不意外中断 CI 的情况下实施管控？
GitHub 建议先在选定的仓库和 workflow 中进行试点。Require lockfile 策略会阻止缺少有效锁文件的目标 workflow 运行，包括没有 uses: 依赖项的 workflow。策略的 Evaluate 模式仅适用于 GitHub Enterprise Cloud。因此，应先准备好覆盖范围和自动更新机制，再启用强制规则。
- 检查源引用。创建锁文件前，请确认 actions 引用的是团队确实希望固定的版本。生成器会固定从当前引用解析出的 commit。
- 创建并审查锁文件。安装
gh-actions-lock扩展，在仓库根目录运行gh actions-lock，并审查完整 diff，包括被改写的uses引用。 - 设置更新与验证。Dependabot 可以更新已接入 workflow 中相应的记录。还可以在 CI 的拉取请求流程中配置验证任务，运行
gh actions-lock --verify，以便在主构建前发现过期的锁文件。 - 指定审查人员。将
.github/workflows/actions.lock加入 CODEOWNERS，并要求由负责构建安全的人员审查相关变更。 - 试运行策略。从已接入的仓库和 workflow 开始。在 Evaluate 模式下分析结果；切换到 Active 模式前，确认所有目标 workflow 都已准备就绪，且锁文件保持最新。
Require lockfile 与单独的 Require actions to be pinned to a full-length commit SHA 策略是不同的规则；GitHub 指出，两者可以同时保留。CI 验证和强制策略也有不同作用：前者会在拉取请求处理期间发现过期文件，后者则会阻止不符合要求的 workflow 运行。
示例：更新部署 action
假设某个 workflow 通过 octo-org/deploy-action@v3 发布应用。首先，团队检查该引用会解析到哪个版本；然后运行 gh actions-lock，并同时审查 workflow 的 diff 和锁文件中的 commit 记录。更新 action 时，审查者可以看到引用和固定 commit 的变更，从而评估具体更新，而不是依赖一个可能移动的标签始终指向相同代码。
如果部署由另一个仓库中的可复用工作流执行，本地锁文件就不会涵盖其依赖。请用完整 SHA 固定可复用工作流的引用，并检查源仓库是否自行管理其 actions 依赖。对于大型组织，这能将零散规则转化为可审计的流程，同时继续单独管理参数、机密信息和 runner。
锁文件是管控 actions 代码的一个有效层面：它让版本和更新变得清晰可见，也涵盖传递依赖。要确保覆盖充分，还应检查可复用工作流和本地 actions、自动化更新，并在试点完成后再引入强制策略。
