GitHub Actions Just Got Lockfiles — Here's How to Use Them

For the past few years, the security advice for GitHub Actions has been straightforward: pin every action to its full commit SHA, not the version tag. Tags can be moved. If someone compromises an action's maintainer account, they can point v4 at completely different code and you'd have no idea.

This isn't theoretical — it's happened.

SHA pinning works, but it makes workflow files unreadable:

- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

GitHub recently shipped a better option: workflow lockfiles.

The concept is the same as package-lock.json or go.sum. You write clean version tags in your workflow files, and a separate lockfile maps those versions to exact commit SHAs. If the upstream tag gets moved, your lockfile still resolves to the original commit.

Here's the setup.

Install the CLI extension

gh extension install github/gh-actions-lock

Generate the lockfile

gh actions-lock

This rewrites your workflow to use readable tags and creates .github/workflows/actions.lock with the SHA mappings.

Add a verification step to CI

This keeps the lockfile in sync:

lockfile:
  runs-on: ubuntu-slim
  steps:
    - uses: actions/[email protected]
      with:
        persist-credentials: false
    - run: gh extension install github/gh-actions-lock --pin v0.4.1
    - run: gh actions-lock --verify

Both Dependabot and Renovate already support lockfile updates, so your regular version bumps keep working without changes.

One useful detail

The lockfile stores the owner_id and repo_id for each dependency. That means it can detect if a tag is pointed at a completely different repository — not just a different commit. Harder to attack.

Is it worth it?

The feature went GA last month. If you've been putting off SHA pinning because it makes your workflows painful to read, this removes that excuse. Five minutes to set up, and your CI supply chain gets meaningfully tighter.