GitHub announced on October 28, 2026 that workflow dependency lockfiles for GitHub Actions are now generally available. It is available to Free and Team accounts as well as both flavors of Enterprise Cloud, following a public preview.
A lockfile lets a workflow keep a readable reference such as a tag or branch, while the runner executes the exact commit that was recorded. For teams worried about supply chain attacks on third-party actions, this closes a long-standing gap between convenience and safety.
What changed
Until now, a workflow that used a moving reference like a major version tag could silently run different code tomorrow than it ran today. Pinning every action to a full commit hash avoided that, but made workflow files hard to read and tedious to update.
Lockfiles split those two concerns. The workflow file stays human friendly, and a separate file records the commits that are actually allowed to run. GitHub Actions then runs the recorded commit even if the tag or branch has since moved.
Key details of the GA release
GitHub lists several capabilities that moved from preview to general availability:
- Generate the lockfile with the gh actions-lock CLI extension, which covers each action plus whatever those actions pull in.
- Roll it out step by step, one workflow at a time. After a workflow is onboarded, all of its dependencies must appear in the lockfile.
- Dependabot refreshes the matching lockfile entry inside its own version-update pull request, so the two never drift apart.
- Administrators at the enterprise, organization or repository level can switch on a Require lockfile policy.
- Detect outdated lockfiles in read-only mode, for example as a CI check.
How the extension works
The gh-actions-lock extension is a GitHub CLI add-on written in Go and released under the MIT license. It pins every direct and transitive action to a verified commit and stores the result in a file named actions.lock inside the workflows folder.
It needs an authenticated gh CLI and supports github.com and Enterprise Cloud with data residency, but not GitHub Enterprise Server.
Running the command onboards or repairs the lockfile. A relock option moves references such as main or v4 to their current upstream commits. A verify mode is meant for CI, while a local verify mode only checks coverage without any network access and does not prove provenance.
When the extension looks up public actions, it uses a github.com token if one is configured. Without a token it falls back to anonymous access, which shares a limit of 60 requests per hour per IP address. Teams running it inside CI should therefore supply a token with public-repository access.
What it means for developers
For most teams, the practical gain is a safer default without rewriting every workflow. You keep writing short references, and the lockfile makes sure a compromised or retagged action cannot slip new code into your pipeline overnight.
GitHub is careful to say that lockfiles do not decide whether a dependency is safe. They only freeze what you reviewed. Review an action before you lock it, and read lockfile diffs in pull requests the same way you read code changes.
There are limits to know about. Reusable workflows called from another repository are not locked, local actions are not followed, and container images are not locked, so images without a digest only trigger a warning. A floating reference that is moved back to an older commit in its history is also not detected, so reviewing diffs still matters.
The feature fits well with other recent GitHub security work. If you already triage alerts with Dependabot reachability analysis or are experimenting with GitHub Agentic Workflows, a locked workflow dependency tree gives those pipelines a more predictable base.
How to get started
Install the extension with the GitHub CLI, run it from your repository, then review and commit the generated lockfile and workflow changes. Start with one or two critical workflows, such as release and deployment pipelines, before onboarding the rest.
After that, add a CI step that runs the verify mode so a stale or tampered lockfile fails the build. Administrators who want organization-wide coverage can then enable the Require lockfile policy once most repositories have adopted it.
Rerun the tool whenever you add a workflow or change a uses line. Let Dependabot handle routine action updates, since it now keeps the lockfile entries in step automatically.
Conclusion
Workflow lockfiles are a small but meaningful hardening step for GitHub Actions. They make the commit that runs in your pipeline explicit and enforceable, without giving up readable workflow files. With general availability on Free and Team plans, even small projects can adopt them today.
Sources
- GitHub Changelog: GitHub Actions workflow lockfiles are generally available
- github/gh-actions-lock repository
See my articles more often when you search Google.
