The Supply Chain Attack Your CI/CD Pipeline Never Saw Coming

Consider what happens every time your team ships code. A GitHub Actions workflow fires off and pulls in third-party actions to run tests, scan for vulnerabilities, and deploy your app. Most teams reference those actions by tag, something like actions/checkout@v4. It reads cleanly, follows standard conventions, and carries a security risk that most teams never stop to examine.

Tags in Git are not immutable. A maintainer can update a tag to point to a completely different commit without touching your workflow file at all. An attacker who has compromised a maintainer’s account can do exactly the same thing. Your workflow still says @v4. The next CI run executes whatever commit that tag currently points to. Those can be entirely different codebases, and your pipeline has no mechanism to notice the change.

GitHub just shipped a direct fix. Workflow lockfiles are now in public preview.

A lockfile is a separate file that records the exact commit hash for every action your workflow depends on, including the actions those actions pull in as their own dependencies. When lockfiles are active, GitHub runs those pinned commits regardless of where the tag currently points. Your workflow keeps its human-readable tag reference. The lockfile makes sure that tag is not the thing actually determining what runs.

Getting started takes about twenty minutes. Install the gh actions-lock extension for the GitHub CLI, run it against your workflows, and it generates a file at .github/workflows/actions.lock containing the specific commits behind every action your pipeline uses. Any workflow you onboard must have all its dependencies recorded in that file before GitHub will allow it to run. Dependabot handles the ongoing maintenance automatically, regenerating the relevant lockfile entry in the same pull request whenever it bumps an action version.

For organizations and enterprises, there is also a policy layer. Administrators can require lockfiles across the entire company, making it impossible for any workflow to run with unpinned dependencies. Teams that need to demonstrate compliance or pass a security audit now have an enforceable mechanism to point to.

Supply chain attacks on CI/CD pipelines have gone from theoretical to common. Attackers target build infrastructure rather than application code specifically because development teams tend to trust whatever their pipelines pull in at runtime. The SolarWinds compromise made this pattern famous. Many variations have appeared since then. Pinning every action to a reviewed commit closes that particular door entirely.

The feature is available now for GitHub Free, Team, Enterprise Cloud, and Enterprise Cloud with data residency plans.

Want to explore how to harden your DevOps pipeline against modern supply chain threats? Let’s talk.