GitHub Actions Lockfiles: Safer CI Dependency Pinning

On October 14, 2026, GitHub opened workflow dependency lockfiles in public preview. The feature lets teams keep readable action references in their GitHub Actions YAML while ensuring that runs execute the exact commits recorded in a separate lockfile. This reduces the risk of a tag or branch moving after a dependency has been reviewed. It is a reproducibility and supply-chain control, not a guarantee that a dependency is trustworthy.

What changes for GitHub Actions

Today, a workflow referencing an action by a version tag can execute different upstream code if that tag moves. A lockfile records the resolved commit and source repository identity for actions, including transitive dependencies, and for reusable workflow references. Once a workflow is onboarded, GitHub Actions checks that its dependencies appear in the lockfile and uses the locked commits. Dependencies inside a called reusable workflow are governed by that reusable workflow's own repository lockfile.

Availability and preview limitations

GitHub's October 14 release, including its same-day correction, lists Free, Team, GitHub Enterprise Cloud and Enterprise Cloud with data residency as eligible plans. The feature is still a public preview, so behavior and tooling can change. GitHub Enterprise Server is not supported by the current CLI extension, and some workflows using local-path actions cannot yet be onboarded. Administrators should test eligibility and avoid treating preview behavior as a permanent contract.

How to evaluate it in one repository

1. Choose a non-critical workflow and inventory its third-party actions and reusable workflow dependencies.
2. Install the official GitHub CLI extension using gh extension install github/gh-actions-lock.
3. Run gh actions-lock in the repository to generate or update .github/workflows/actions.lock; review the generated changes before committing.
4. Commit the reviewed lockfile with its workflow changes, then run the workflow and confirm it uses the expected dependencies.
5. Add gh actions-lock --verify to a CI check so missing or stale entries are caught without silently rewriting them.
6. Use Dependabot updates to refresh locked dependencies through reviewed pull requests rather than leaving pins frozen indefinitely.

Lockfiles versus manual SHA pinning

Manually pinning every action to a full commit SHA also avoids mutable tags, but it can be tedious to audit and maintain. GitHub's lockfile approach keeps familiar YAML references while recording exact commits, transitive dependencies and source repository identifiers in one reviewable file. A lockfile is not a vulnerability scanner: teams still need to evaluate the action publisher, permissions, release provenance and updates.

Policy, Dependabot and the rollout decision

A Require lockfile policy is also in preview for administrators who want to enforce adoption. GitHub says Dependabot can regenerate relevant lockfile entries in the same pull request when updating an action already covered by a lockfile. Start with a small pilot, compare maintenance overhead and verify that every dependency change receives code review. Treat failures as signals to investigate, not invitations to bypass checks.