GitHub Actions supply chain: pinning tags is not enough

Mutable action tags keep getting retargeted to malicious commits. A tag you pinned last month can point at attacker-controlled code today, and your workflow will happily run it with your secrets in scope.

Why it matters

We caught it on a client's pipeline: a widely used setup-action we'd all pinned to the latest v14 tag started running an attacker-controlled script during the install step. The tag hadn't been changed — someone had just deleted and recreated it to point at a different repository.

It works because actions/checkout@v14 resolves to whichever commit the v14 tag currently references. There's no guarantee that v14 always maps to the same commit, even if the maintainer seems reputable. And the GitHub UI won't tell you your workflow is pointing at a tag that suddenly moved.

What we recommend

1. Always pin to a commit SHA. @ followed by a full 40-character SHA (e.g. @ab12cd34ef567890) is immutable. GitHub Actions doesn't support a shorthand for pre-fetching and verifying that SHA, so you may need to update the workflow manually, but it's the only truly safe approach.
2. Audit your workflows regularly. Use dependabot or a scheduled pipeline to check whether pinned tags have moved. A simple git ls-remote --tags origin against the action's repo is enough.
3. Consider a private mirror. If your org publishes frequently used actions, mirroring them into a private GitHub organisation gives you complete control over versions and removes supply-chain risk entirely.

The fix we deploy by default

Every GitHub Actions workflow generated by chaosbyte gets pinned to a SHA by default, and we alert the client if a tag ever retargets. It's not perfect, but it beats trusting mutable pointers.