GitHub Actions lockfiles move invisible changes into review

Event date: 14 October 2026. GitHub released workflow dependency lockfiles for GitHub Actions in public preview. The feature is available on Free, Team and GitHub Enterprise Cloud plans. A workflow may retain a readable tag or branch reference while GitHub runs the exact commit recorded in .github/workflows/actions.lock.

What is actually locked?

gh actions-lock records the commit and numeric repository identity for an action. It covers direct actions, their transitive action dependencies and references to reusable workflows. There is an important boundary: dependencies inside a called reusable workflow are governed by the lockfile in the repository that defines that workflow.

Why is this an architecture decision?

A CI/CD workflow is part of the delivery supply chain. A reference such as uses: vendor/action@v3 may resolve to different code after the tag moves, with no change in the consuming repository. A lockfile moves that invisible change into a reviewable diff. It provides repeatable execution, an inventory of pipeline dependencies and a control point for updates.

What does a lockfile not guarantee?

• It does not prove that the locked code is safe.
• It does not replace least-privilege GITHUB_TOKEN permissions, secret protection or runner isolation.
• It does not automatically lock container images, packages and scripts downloaded by the action itself.
• It does not remove the need to update. An old, known commit may contain a known vulnerability.

A pilot plan

1. Select a repository without a critical release path and inventory uses:, reusable workflows and local actions.
2. Review current references, generate the lockfile and inspect the complete diff. The generator may make workflow version references more specific.
3. Add gh actions-lock --verify as a pull-request check. Route lockfile changes to the owner of pipeline security.
4. Configure Dependabot for GitHub Actions and test an update, rollback and moved-tag case.
5. Only then consider requiring a lockfile. GitHub documentation notes that policy Evaluate mode is available only on Enterprise.

ArchitectMentor interpretation

The main value is not another YAML file. It is moving an invisible dependency change to a place where it can be seen, assessed and approved. Without review of the diff, a lockfile is merely an elegant way to keep running code nobody examined.