A typical workflow after lockfile conversion, with actions pinned to version tags and a companion lockfile documenting exact commits.
GITHUB ACTIONS LOCKFILES ARRIVE TO BLOCK SUPPLY‑CHAIN ATTACKS
*GitHub now ships workflow lockfiles to freeze action versions. The move curbs mutable tag exploits that have plagued CI pipelines. Developers can lock down dependencies with a single CLI extension.*
GitHub Actions have become a favorite automation layer for developers, but their reliance on Git tags opened a silent backdoor. An attacker can retag a safe reference, slipping malicious code into any pipeline that still points at the mutable tag. Hugo van Kemenade’s recent guide shows how GitHub’s new workflow lockfiles seal that gap. By converting tag references into immutable version pins and recording the exact commit details, lockfiles turn a fluid dependency model into a verifiable, static one.
The lockfile workflow is simple: install the `gh-actions-lock` CLI extension, run it, and commit the generated `.github/workflows/actions.lock`. The file lists each action’s version, ref, SHA, owner_id and repo_id. Once in place, any deviation between the workflow and the lockfile triggers a CI failure, giving teams immediate visibility into tampering attempts.
Why mutable tags are a supply‑chain risk
GitHub Actions are fetched from Git. Tags can be retagged, letting an attacker point a previously safe tag at malicious code. The source example shows a workflow that used a tag‑based reference, which is vulnerable. By pinning to a full SHA, the reference becomes immutable. Lockfiles automate this pinning, replacing tag strings with explicit version tags like @v7.0.1. The lockfile records the exact commit SHA, owner and repo IDs, ensuring the CI runner cannot be hijacked by a later tag change.
How do you enable lockfiles in a repo?
Install the gh‑actions‑lock extension: `gh extension install github/gh-actions-lock`. Run `gh actions-lock` in the repository root. The command validates all workflows, reports any invalid ones, and writes a machine‑generated lockfile at `.github/workflows/actions.lock`. The lockfile lists each action, its version tag, ref, commit SHA, owner_id and repo_id. After locking, the workflow file swaps the SHA reference for a version tag, as shown in the diff example. The process is repeatable; any new workflow file requires a fresh `gh actions-lock` run to keep the lockfile in sync.
Can existing automation tools work with lockfiles?
Both Renovate and Dependabot already understand lockfiles. Their periodic updates will refresh the lockfile when they bump an action version. GitHub also recommends adding a verification job to CI. The sample `verify-lockfile.yml` runs `gh actions-lock --verify` on an ubuntu‑slim runner, failing the build if the lockfile drifts from the workflow definitions. This extra gate catches accidental or malicious changes before they reach production.
What other security linters complement lockfiles?
The article cites zizmor, a security linter for GitHub Actions. Versions before v1.32.0 only advise hash‑pinning actions; v1.32.0 is the first to support lockfiles. Adding zizmor to a `.pre-commit-config.yaml` with `rev: v1.32.0` ensures every commit is scanned for insecure action references. The author notes that using zizmor in the pre‑commit pipeline reinforces the lockfile strategy, creating a layered defense against supply‑chain tampering.
Frequently asked questions
How do lockfiles prevent malicious tag changes in GitHub Actions?
Lockfiles replace mutable tag references with explicit version tags and record the exact commit SHA, so a later tag change cannot affect the workflow.
What command generates the .github/workflows/actions.lock file?
Running `gh actions-lock` after installing the `gh-actions-lock` extension creates the lockfile and validates all workflows.
Do Renovate and Dependabot work with GitHub Actions lockfiles?
Yes, both tools already support lockfiles and will update them when they bump action versions.
Adopting lockfiles is no longer optional for security‑conscious teams. The built‑in GitHub support, combined with existing tools like Renovate, Dependabot and zizmor, creates a turnkey defense against tag‑based supply‑chain attacks. As CI pipelines grow more complex, the lockfile’s audit trail offers the only reliable way to guarantee that the code you run is exactly the code you approved. Teams that ignore it leave a gaping hole for attackers to exploit.
Sources: [Hacker News – Lock Your GitHub Actions]