GitHub Actions workflow lockfiles are in public preview. Here is how to turn them on, check them in CI, and what they do not protect.

A workflow that says uses: some/action@v4 trusts a moving target. GitHub's changelog puts it plainly: tags and branches can move after you review a workflow, so a later run might execute different code. If an action is compromised, a moved tag or branch can introduce malicious code into your workflow without any change to your repository.

A lockfile keeps the references in your workflow and makes the runner execute the exact commits you locked. Your workflow file still reads the way you wrote it, and the lockfile decides what actually runs.

The extension needs the gh CLI and does not support GitHub Enterprise Server. Install it, run it from the repository, then review and commit what it generates. Per the README, the first run scans every workflow under .github/workflows, pins each resolvable action to a SHA, and writes the lockfile. Workflows are onboarded to the lockfile one at a time.

Once a workflow is onboarded, every dependency must have a lockfile entry, and the runner uses the recorded commit even if a tag or branch has since moved. The README says each locked pin is checked again the way the runner checks it at job start: the repository was not renamed or transferred, the pinned commit still exists, and full version tags such as v4.2.1 still point at it. Redirects and identity mismatches are blocked at runtime.

Locked actions must also have a branch that contains the locked commit, which the README says makes impostor commit style attacks harder.

A lockfile that nobody verifies drifts. The README gives two checks. gh actions-lock --verify runs the full check without writing anything, and is the one for CI. It also checks that a commit locked under a branch or partial version such as main or v4 is still in that ref's history. gh actions-lock --verify-local runs offline and only checks that every reference has an entry, not that the entries are trustworthy, so the README says to use --verify in CI.

Writes are all or nothing: if a run finds an error it cannot fix, it changes no workflow and no lockfile entry, even for workflows that are otherwise fine.

Locked pins are sticky, so a normal run only resolves references the lockfile does not record yet, and pins to branches or partial versions do not advance when upstream moves. gh actions-lock --relock regenerates the lockfile from the current upstream commits. A suspicious pin, whose recorded commit is no longer reachable upstream, is left as an error, and --accept-moved resolves those as well. Treat an unreachable commit as something to investigate before you accept it.

Dependabot helps with the routine updates. When it opens a version update for an action in an onboarded workflow, it also regenerates the matching lockfile entry in the same pull request. Admins can require lockfiles across an enterprise, organisation or repository with the Require lockfile policy, also in public preview.

GitHub says it directly: locking does not determine whether the dependency itself is safe, so review dependencies before locking them. A lockfile reliably runs whatever you pointed it at, which includes a version that was already compromised when you locked it.

It is also early. The README calls the tool pre 1.0, warns that the lockfile format, command flags and behaviour may change without notice, and lists local path actions as a short term gap. Expect to revisit your setup as it changes, and keep your own pinned SHAs for anything critical in the meantime.

Onboard the workflows that hold secrets first: deploys, releases, package publishing and anything that authenticates to a cloud account. A moved tag in one of those is the expensive case, and they are usually a handful of files. Move the rest across once the CI check has run clean for a week.