GitHub Actions now supports workflow dependency lockfiles in public preview for Enterprise Cloud and Enterprise Cloud with data residency. By recording the specific commit SHA for each action, reusable workflow, and transitive dependency, the platform ensures that a run executes the exact code you reviewed, even if the original tag or branch later points elsewhere. This directly addresses the risk of silent code changes in CI pipelines.
What are GitHub Actions lockfiles?
A lockfile, stored as .github/workflows/actions.lock, lists the commit SHA for every dependency referenced in a workflow file. When a workflow is marked as “onboarded,” GitHub Actions reads the lockfile and forces the run to use those recorded commits, ignoring any later movement of tags or branches. The lockfile is a plain‑text, reviewable artifact that can be version‑controlled alongside the workflow definition.
Adopting lockfiles in existing pipelines
The gh actions-lock extension for the GitHub CLI creates and maintains the lockfile. Running the extension generates entries for direct actions, their transitive dependencies, and any reusable workflows. Teams can adopt the feature incrementally: each workflow can be onboarded individually, and only onboarded workflows are required to have matching lockfile entries. An optional “Require lockfile” policy, also in public preview, lets enterprise, organization, or repository administrators enforce lockfile usage across all workflows under their control.
Operational and security implications
Lockfiles eliminate the surprise of a tag or branch moving after a workflow review, which could otherwise introduce malicious code without a repository change. However, the lockfile does not guarantee that the locked commit is safe; engineers must still vet actions before locking them. To keep lockfiles current, GitHub provides a “check for stale lockfiles” command that can be run in CI without modifying files. Dependabot integration further streamlines maintenance: when Dependabot opens a version‑update PR for an action, it also updates the corresponding lockfile entry in the same PR, keeping the workflow reference and its locked commit synchronized.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Start by installing the gh actions-lock extension and generating a lockfile for a low‑risk workflow. Review the generated .github/workflows/actions.lock entries, commit the file, and enable the “Require lockfile” policy at the appropriate scope once you are comfortable with the process. Integrate the stale‑lockfile check into your CI linting stage, and rely on Dependabot to keep the lockfile up to date with action version bumps. By pinning exact commits, you gain deterministic builds and a clearer audit trail, while still needing to assess the security of the locked code itself.
