GitHub Actions Locks Down Workflows With Public Preview Lockfiles

On October 14, 2026, GitHub opened public preview access to workflow dependency lockfiles for GitHub Actions. The feature addresses a known blind spot in CI/CD pipelines: a workflow that references an action by its tag (uses: owner/action@v3) can run different code from one run to the next if that tag gets moved, including after a compromise of the action’s repository. Lockfiles pin every dependency to a reviewed commit, without changing the syntax of existing workflows.

#The problem: tags that can move

In a typical GitHub Actions workflow, tag or branch references guarantee nothing about the stability of the code being run: a maintainer can reassign a tag to a new commit, intentionally or after a repository takeover. It’s one of the most documented supply-chain attack vectors on CI/CD platforms, and until now the only reliable defense was manually pinning every action to a commit hash, a practice rarely kept up to date.

#How lockfiles work

The implementation ships as a GitHub CLI extension, gh actions-lock, which generates a .github/workflows/actions.lock file. That file records which commits to use for each action, including their transitive dependencies and any reusable workflows called. Adoption happens one workflow at a time: once a workflow is onboarded, every one of its dependencies must appear in the lockfile, and GitHub Actions then runs exactly the recorded commits.

gh extension install github/gh-actions-lock
gh actions-lock init
gh actions-lock verify

The verify command checks that the lockfile is current without modifying any files, which makes it easy to wire in as a required pull request check rather than something run only locally.

#Dependabot and enforcement policy

When Dependabot opens a version update for an action that’s already locked, it automatically regenerates the matching lockfile entry in the same pull request, with no extra configuration needed. Alongside this, a “Require lockfile” policy, also in public preview, lets an administrator enforce lockfile use at the enterprise, organization, or repository level.

Locking a dependency pins a specific revision, but it does not guarantee that revision is safe: reviewing the code stays the responsibility of the team that adopts it.

Adoption stays voluntary until an administrator turns on the “Require lockfile” policy, which gives teams time to migrate their most sensitive workflows first, typically the ones touching deployment or package publishing. For a team that already practices systematic hardening of its production environments, workflow lockfiles fit the same logic: shrinking the attack surface by eliminating moving references instead of monitoring them after the fact.

#Getting started

The extension installs from the public github/gh-actions-lock repository, alongside the usual roster of command-line tools developers reach for in day-to-day web development work. After generation, the lockfile and the workflow changes it entails should be reviewed and committed like any other CI configuration change.

#Key takeaways

• Workflow lockfiles pin every GitHub Actions action to a specific commit, instead of a tag or branch that can move.
• Adoption happens workflow by workflow through the gh actions-lock extension, with a check that can run in CI.
• Dependabot automatically regenerates lockfile entries during version updates.
• An enforcement policy exists at three levels, but stays optional until an administrator turns it on.
• Locking protects against a tag being moved, not against a dependency that was already malicious at the moment it got pinned.

Further reading: the official announcement on the GitHub changelog.