Pin Your GitHub Actions Dependencies Before a Supply Chain Attack Does It for You

Every CI/CD pipeline is built on trust. You reference a third-party GitHub Action in your workflow, it runs inside your build environment, and it has access to your code, your secrets, and your deployment targets. That is a significant amount of trust to place in something that can silently change underneath you.

GitHub just made that trust verifiable.

Workflow dependency lockfiles are now in public preview for GitHub Actions. The concept works exactly like a package lockfile in Node.js or Python. A package-lock.json file pins the exact version of every dependency so that running your build today produces the same result as running it six months from now. Workflow lockfiles do the same thing for GitHub Actions, resolving each referenced action to a specific commit SHA rather than a floating tag like v3 or main. A commit SHA is a unique fingerprint that identifies exactly which snapshot of code ran at a given moment in time. Tags, by contrast, can move.

This is the attack surface that has caused real damage. Tags in Git are not immutable. A repository owner can point a tag at a completely different commit at any time. If you reference a third-party action by tag, and an attacker gains control of that repository, they can push new malicious code under the same tag and your workflow will run it without any indication that anything changed.

This is exactly how the tj-actions/changed-files supply chain attack played out in early 2025. Attackers compromised a widely used GitHub Action, moved its tags, and thousands of downstream CI workflows unknowingly executed malicious code. Credentials were leaked. Repositories were compromised across hundreds of organizations.

Lockfiles close that attack surface permanently. When you generate a lockfile using the new GitHub CLI extension, every action in your workflow is resolved to its exact commit SHA and recorded in a file at .github/workflows/actions.lock. From that point forward, GitHub Actions enforces those commits. Even if an upstream tag moves or a repository is compromised, your workflow runs only the code you reviewed and locked.

The workflow file still references readable version tags, so your YAML stays human-friendly. The lockfile handles the pinning in the background. Dependabot integration keeps everything current by regenerating lockfile entries automatically whenever it opens version-update pull requests, so you are not stuck manually maintaining the lock file as dependencies evolve.

Setup takes about ten minutes. Install the gh actions-lock CLI extension, run the generate command in your repository, commit the resulting file, and you are done. Enterprise and organization administrators can require lockfiles across an entire tenant with a single policy setting.

For teams shipping software to clients, this is a straightforward security improvement that reduces real risk without slowing down daily development. The changes that matter most are often the ones that prevent problems nobody ever sees. This is one of those changes.

Want to explore how better DevOps practices could benefit your business? Let’s talk.