CI/CD流水线正在成为软件供应链攻击的高价值目标。GitHub Actions workflow dependency lockfiles 现已进入公开预览，面向 GitHub Enterprise Cloud、GitHub Enterprise Cloud with data residency、Team 和 Free 计划开放。它要解决的核心问题很具体：tag 和 branch 在审查之后仍可能移动，导致后续运行执行与审查时不同的代码。
问题：tag 会漂移，审查会失效
在 GitHub Actions 中，workflow 通常以 uses: owner/action@v3 这类引用声明依赖。tag 和 branch 是可变引用，维护者可以随时把 v3 指向新的 commit。如果某个 action 被攻陷，移动的 tag 或 branch 可以在你的仓库没有任何变更的情况下，把恶意代码引入 workflow。这不是假设性风险，而是官方明确指出的攻击路径。
lockfile 的思路是：保留 workflow 中可读的引用写法，但实际运行时使用被锁定的确切 commit。这样既维持了可维护性，又把执行内容固定下来。
lockfile 锁什么
通过 GitHub CLI 的 gh actions-lock 扩展，可以生成 .github/workflows/actions.lock。锁定的对象包括：
- actions 及其传递依赖的可审查 commit；
- 可复用 workflow 依赖。
需要注意边界：锁定不判断依赖本身是否安全。官方明确说明，lockfile 只防止依赖发生意外变化，不评估依赖的安全性。因此锁定之前仍需审查依赖。
渐进式接入与运行一致性
lockfile 支持按 workflow 逐个接入。一旦某个 workflow 被接入，它必须为所有依赖提供 lockfile 条目，GitHub Actions 会运行记录的 commit。即使 tag 或 branch 移动，运行仍使用锁定 commit。
这种“接入即强制”的语义意味着迁移需要分批推进：先选低风险 workflow 验证，再逐步扩大范围。扩展还提供 stale lockfile 检查，可以在不修改文件的前提下验证 lockfile 是否最新，适合放进 CI 检查。
Require lockfile 策略
公开预览同时提供 Require lockfile 策略。企业、组织和仓库管理员可以在对应层级要求 workflow 使用 lockfile。这为平台团队提供了强制基线：不需要逐个仓库沟通，而是通过策略统一约束。
与 Dependabot 联动
Dependabot 负责保持 GitHub Actions 依赖更新。当它为已接入的 workflow 打开 action 版本更新时，会在同一个 pull request 中重新生成对应的 lockfile 条目，使更新后的 workflow 引用与锁定 commit 保持同步，无需额外配置。这解决了 lockfile 最常见的运维痛点：锁定之后如何持续更新而不手工维护。
对 AI 项目的工程建议
AI 项目的流水线通常包含模型训练、评估、Agent 部署等环节，依赖链长、第三方 action 多，tag 漂移的影响面更大。结合官方能力，可以按以下顺序推进：
- 盘点依赖：列出 workflow 中所有 action 与可复用 workflow，优先处理涉及凭据、制品发布、部署的环节。
- 安装扩展并生成 lockfile：使用
gh actions-lock生成.github/workflows/actions.lock，审查其中的 commit 后提交。 - 逐个接入：从非关键路径开始，确认运行一致后再推进到训练与部署流水线。
- 加入 CI 检查：用 stale lockfile 检查防止 lockfile 与 workflow 脱节。
- 启用策略：在组织或仓库层评估 Require lockfile，形成强制基线。
- 依赖 Dependabot：让版本更新与 lockfile 再生成在同一 PR 中完成。
需要强调的是，lockfile 是供应链安全的一层控制，不是全部。它保证“运行的是审查过的 commit”，但不保证“审查过的 commit 是安全的”。依赖审查、最小权限 token、环境审批等实践仍需并行。
如何开始
从公开的 gh-actions-lock 仓库安装扩展，审查并提交生成的 lockfile 与 workflow 变更。详细设置说明见 GitHub Docs 的 workflow dependency lockfiles 页面。反馈可以提交到社区讨论或 gh-actions-lock 仓库的 issue。