Lock Your GitHub Actions
GitHub Actions 已正式支持 workflow lockfiles，这标志着开发者保障 CI/CD pipelines 的方式出现了重大变化。过去的通用安全建议是把 actions 固定到特定的 SHA 哈希上，以规避可变标签带来的风险，因为这些标签可能会被恶意方篡改。借助这一新能力，开发者既能继续使用更清晰、更易读的标签，又能确保底层代码始终锁定在经过验证的版本上。
要使用它，开发者可以在 GitHub CLI 中安装 gh-actions-lock 扩展。安装完成后，运行相应命令会自动把 workflows 更新为使用版本标签，并在代码库中生成一个集中式的 actions.lock 文件。该文件作为单一事实来源：它会将特定的 actions 映射到对应的提交 commit SHA 、 owner ID 以及 repository ID 。完成首次锁定后，只需把这些改动提交到代码库，就能最终落地安全配置。
依赖管理仍然很省事，因为 Renovate 和 Dependabot 已经都支持这些 lockfiles 。这意味着自动化的依赖更新会同时包含对 lockfile 的必要调整，只要用户遵循依赖冷却时间等最佳实践即可。此外，强烈建议在 CI 中校验这些文件的完整性。通过在 workflow 中新增专门的校验任务，你可以确保 lockfile 始终与当前配置保持一致，并且不会被破坏或篡改。
与此同时，安全性检查工具 zizmor 也已更新：在最新版本中支持 lockfiles 。把 zizmor 集成到 pre-commit hooks 或 CI pipeline 中，可以为 GitHub Actions 配置增加一层额外的自动化安全分析。将这些现代锁定机制与成熟的安全 lint 工具结合起来，开发者能够显著降低供应链攻击风险，从而让自动化流程既保持最新，也更安全。
GitHub Actions has officially introduced support for workflow lockfiles, marking a significant shift in how developers can secure their CI/CD pipelines. Historically, the standard security advice was to pin actions to specific SHA hashes to avoid the risks associated with mutable tags, which could be compromised by malicious actors. With this new feature, developers can maintain cleaner, human-readable tags while ensuring that the underlying code remains locked to a verified version.
To take advantage of this, developers can install the gh-actions-lock extension for the GitHub CLI. Once installed, running the command automatically updates workflows to use version tags and generates a central actions.lock file in the repository. This file acts as a source of truth, mapping specific actions to their corresponding commit SHAs, owner IDs, and repository IDs. After performing the initial lock, users simply need to commit these changes to their repository to finalize the security configuration.
Managing these dependencies remains straightforward as both Renovate and Dependabot have already added support for these lockfiles. This means automated dependency updates will include the necessary adjustments to the lockfile, provided users incorporate best practices like dependency cooldowns. Furthermore, it is highly recommended to validate the integrity of these files within CI. By adding a dedicated verification job to your workflow, you can ensure that the lockfile is always in sync with your configurations and not corrupted.
Complementing this, the security linter zizmor has been updated to support lockfiles in its latest versions. Integrating zizmor into your pre-commit hooks or CI pipeline provides an extra layer of automated security analysis for your GitHub Actions configurations. By combining these modern locking mechanisms with established security linting tools, developers can significantly reduce the risk of supply-chain attacks, ensuring their automation remains both current and secure.
64 comments • Comments Link
- GitHub 的新 workflow lockfiles 提供了一种机制，用于锁定 direct 和 transitive dependencies，从而修补长期存在的供应链安全漏洞：sub-actions 可能被恶意替换。
- 尽管引入了 lockfiles，但仍有一些缺口无法覆盖，例如无法锁定 Docker images 、 composite action 的内部实现，以及底层 runner environments（如 `ubuntu-latest`）。
- 当前做法需要借助 `gh actions-lock` 工具，部分人认为这增加了不必要的复杂度。批评者建议 GitHub 应当把 marketplace tags 原生设为不可变（immutable），这样就不需要额外工具或 lockfiles 。
- 与其把验证负担转嫁给消费者去维护并审计复杂的 lockfile dependencies，不如采用可信且不可变的 tags 作为更优的安全模型。
- 是否有必要使用第三方 actions 存在很大争议。一些开发者主张直接把代码复制粘贴到自己的 repositories 中，以确保完全可控，而不是依赖不透明的上游脚本。
- 仅有 lockfile 仍然无法解决信任这一根本问题。若第三方 action 的入口点被入侵或本身携带恶意，lockfile 只能保证攻击者的代码被持续执行。
- 在社区的部分群体里，GitHub Actions 常被认为是次优选择：有人更倾向于使用 Jenkins 这类自托管方案，或用 cron 触发的简单 shell scripts，以换取更强的透明度与控制力。
- 对于那些觉得 GitHub 生态过于不透明或不够安全的人来说，自托管 CI infrastructure 正逐渐成为可行替代方案，尤其是在 LLMs 让维护复杂构建系统变得更可控之后。
- 对于面向多平台的项目，基本共识仍是本地测试至关重要，因为依赖非个人维护的平台 CI environments，往往会在维护与虚拟化方面遇到障碍。
- lockfile 虽然是供应链安全的重要基石，但它更像权宜之计，而不是对最初就未把稳健依赖管理纳入设计的系统进行根本修复。
这场讨论反映出对 GitHub Actions 作为平台的深层不信任：有人认为它对敏感 workflows 从根本上不安全。大家都承认引入 lockfiles 是修补 transitive dependency 漏洞的必要步骤，但不少贡献者认为这带来了不必要的复杂性，并未触及"默认信任"模型这一根本原因。反复出现的观点是对简单性的追求——无论是通过自托管、在本地 vendored 依赖，还是坚持使用基础脚本——目的都是降低 marketplace 生态中固有的风险。最终分歧变得很清晰：一方认为渐进式的工具更新是 GitHub 平台的积极演进；另一方则认为该系统的架构已难以修复，更倾向于回归到透明度更高、由手工掌控的构建流程。 • GitHub's new workflow lockfiles provide a mechanism for pinning both direct and transitive dependencies, addressing a long-standing supply-chain security vulnerability where sub-actions could be swapped out maliciously.
• Despite the introduction of lockfiles, several gaps remain, including the inability to lock Docker images, composite action internals, and the underlying runner environments like `ubuntu-latest`.
• The current implementation requires the `gh actions-lock` tool, which some argue adds unnecessary complexity. Critics suggest that GitHub should instead make marketplace tags natively immutable, a solution that would require no additional tooling or lockfiles.
• Trusted, immutable tags would arguably be a superior security model compared to the current system, which shifts the burden of verification onto the consumer to manage and audit complex lockfile dependencies.
• There is significant debate regarding the necessity of third-party actions, with some developers advocating for copy-pasting code into their own repositories to ensure complete control, rather than relying on opaque upstream scripts.
• Using a lockfile still does not solve the fundamental problem of trust. If a third-party action is compromised or malicious at the entry point, the lockfile only ensures the attacker's code is consistently executed.
• GitHub Actions is often viewed as a suboptimal ecosystem by a vocal segment of the community, with some preferring self-hosted solutions like Jenkins or simple shell scripts triggered by cron for better transparency and control.
• Self-hosting CI infrastructure is increasingly seen as a viable alternative for those who find the GitHub ecosystem too opaque or insecure, especially with LLMs making the maintenance of complex build systems more manageable.
• For projects targeting multiple platforms, the consensus remains that local testing is essential, as relying on CI environments for platforms one does not personally maintain can be fraught with maintenance and virtualization difficulties.
• While the lockfile feature is an important building block for supply-chain security, it remains a workaround rather than a foundational fix for a system that was not originally designed with robust dependency management in mind.
The discussion reflects deep-seated skepticism toward GitHub Actions as a platform, viewing it as fundamentally insecure for sensitive workflows. While the introduction of lockfiles is acknowledged as a necessary step toward addressing transitive dependency vulnerabilities, many contributors argue that it introduces unnecessary complexity and fails to address the root causes of the "trust-by-default" model. A recurring theme is the preference for simplicity—whether through self-hosting, keeping dependencies vendored locally, or sticking to basic scripts—to mitigate the risks inherent in the marketplace ecosystem. Ultimately, there is a clear divide between those who see incremental tooling updates as a positive evolution for GitHub's platform and those who view the system's architecture as beyond repair, favoring a return to more transparent and manually controlled build processes.