GitHub Actions gets lockfiles so a moved tag cannot change your CI
A public preview feature pins workflow dependencies to specific reviewed commits, closing the gap where a shifted tag or branch quietly swaps in different code.
GitHub launched workflow dependency lockfiles for Actions in public preview on 14 October. The problem they fix: a workflow that references an action by tag or branch can end up running different code later, if that tag or branch gets moved after you reviewed it. A lockfile ties the run to the exact commit you approved instead.
Lockfiles live at .github/workflows/actions.lock and are generated with a new gh actions-lock CLI extension, which records reviewable commits for an action and its transitive dependencies. Adoption is gradual: you can onboard workflows one at a time, and admins can set a “Require lockfile” policy at the repository, organisation, or enterprise level. Dependabot already knows about the file: when it opens a version-bump PR for a locked workflow, it regenerates the matching lockfile entry in the same PR.
gh actions-lock generate # writes .github/workflows/actions.lockWhy it matters: pinning actions to a SHA instead of a tag has been the recommended defence against a compromised or hijacked action for years, but doing it by hand across many workflows is tedious and easy to let drift. Lockfiles make that practice a first-class, enforceable setting instead of a convention everyone forgets.
The caveat: it’s public preview, and only on GitHub Enterprise Cloud and GitHub Enterprise Cloud with data residency, so it is not yet available on github.com’s free or Team plans.