Lock Your GitHub Actions

Workflow lockfiles, which GitHub made generally available on October 28 for Free, Team and Enterprise Cloud plans, give GitHub Actions users a way to keep readable version tags in their workflows while still running exactly the commits they locked. An action is a reusable step, such as checking out a repository, that a workflow fetches from another project's Git repository by tag, for example v7.0.1. Tags can be moved, so an attacker who gains control of an action's repository can point a trusted tag at malicious code. That happened in March 2025, when every tagged version of the tj-actions/changed-files action was redirected to a commit that printed repository secrets into build logs, according to Legit Security. The standard defense was to pin each action to its full commit hash, a long fingerprint that cannot be reassigned, at the cost of workflow files full of long hexadecimal strings with the real version left in a comment.

In a step-by-step post, Hugo van Kemenade shows how he converted his own repositories. He installs GitHub's gh-actions-lock extension for the gh command-line tool and runs gh actions-lock, which rewrites each hash pin back to a plain tag and generates .github/workflows/actions.lock, a machine-written file that records the exact commit behind every tag. GitHub then runs the recorded commit even if the tag later moves. He notes that Renovate and Dependabot, the bots that open pull requests to update dependencies, already update the lockfile along with the workflow. Following GitHub's advice, he adds a separate CI job that runs gh actions-lock --verify, which fails when the lockfile is out of step with the workflows or a locked commit can no longer be verified against the upstream repository. He also upgrades zizmor, a security linter for GitHub Actions, to v1.32.0, the first version that accepts lockfiles instead of telling users to hash-pin. His post links pull requests applying the change to Pillow and several python organization repositories, including CPython.

The protection is narrower than the name may suggest. GitHub's announcement says lockfiles guard against unexpected dependency changes but do not determine whether a dependency is safe, and its enforcement documentation adds that a lockfile is only a security control if someone reads its diff, since a changed commit hash means the code being run has changed. GitHub also tells users to review dependencies before locking them. That advice matters because a lockfile preserves whatever commit it records, including one that was malicious from the start. The post is one maintainer's how-to rather than an evaluation, and it leaves a loose end he acknowledges: his verify job installs the extension pinned to v0.4.1, which he will have to update by hand or find a way to automate. For anyone already hash-pinning, the practical gain is readable workflows with the same commit-level guarantee, plus update bots and a linter that now understand the format.