GitHub Actions adds workflow lockfiles, replacing SHA-pinning for supply-chain security

GitHub Actions gains lockfile support

GitHub Actions now supports workflow lockfiles, a change walked through in a November 2026 blog post on hugovk.dev. Until now, the standard defence against tampered actions was to reference each one by its full commit SHA directly in the workflow file. Because actions are fetched from Git repositories, tags are mutable: someone with write access to an upstream repo can retarget a tag that users already trust and silently redirect it at malicious code. SHA pinning prevented that, at the cost of readability.

The lockfile approach keeps the human-readable version tag in the workflow and records the exact commit it must resolve to in a separate, machine-generated file.

How it works

The mechanism is driven by a gh CLI extension. Installing github/gh-actions-lock and running gh actions-lock inside a repository validates the workflows, rewrites each uses: line from a raw commit hash back to a tag such as actions/[email protected], and generates .github/workflows/actions.lock.

The lockfile records each dependency's ref and commit SHA, along with numeric identifiers for the owning account and the repository. Its header states plainly that it is machine-generated: do not edit it by hand, rerun the tool to update it.

Keeping the lockfile honest

Two things must happen for the scheme to hold up over time: the lockfile needs to track dependency updates, and something needs to check it in CI.

According to the hugovk.dev post, both Renovate and Dependabot already support the new format, so scheduled dependency updates will bump the lockfile alongside the workflow references. The author recommends using cooldowns to pace those updates.

GitHub additionally recommends verifying lockfiles in CI to confirm they stay in sync with the workflows and are not corrupt, and publishes a verify-lockfile.yml workflow that repositories can copy. The post's author instead folded the check into an existing lint workflow as a standalone job that runs in parallel, installing the extension — itself pinned to v0.4.1 — and running gh actions-lock --verify, with the lighter ubuntu-slim runner handling the job.

One operational wrinkle the author flags: after editing a workflow, including when adding the verification job itself, you need to rerun gh actions-lock so any newly referenced actions are covered. CI will flag the gap if you forget.

Tooling is catching up

The post also highlights zizmor, a security linter for GitHub Actions that the author strongly recommends. Versions before v1.32.0 instructed users to hash-pin their actions; v1.32.0 is the first release to understand lockfiles, superseding that advice.

Adoption is already under way in the Python ecosystem, with lockfile conversions proposed for python/cpython, python-pillow/Pillow, python/release-tools and python/miss-islington.

Why it matters

SHA pinning worked, but at a real cost: a workflow full of 40-character hashes tells you nothing about which version of an action you are running, and diffs become noise that reviewers learn to skim past. Lockfiles split those concerns — humans read tags, machines verify commits — in the same way package-lock files decoupled semantic versions from integrity for npm-style package managers.

Recording the owner and repository identifiers alongside each commit also gives verification something stronger than a bare string to check against, making a swapped-out upstream repository harder to slip through. With Renovate, Dependabot and zizmor already supporting the format, the migration path away from hand-maintained hashes is short, and CI verification closes the loop.