Safeguard
Developer Tools•

Pin GitHub Actions to a commit SHA: what tag repointing taught us

Release tags can be moved. After the Trivy and tj-actions incidents, here is how to pin Actions to full commit SHAs without letting updates rot.

Safeguard Security Team
3 min read

Pin third-party GitHub Actions to a full commit SHA, not a version tag. Tags are labels that the owner, or an attacker with the owner's access, can repoint. Wiz reported that 75 of 76 trivy-action tags were force-pushed to malicious versions in March 2026.

Why tags are not a pin

A line such as uses: owner/action@v1 asks GitHub for whatever that tag points to when the job starts. If the tag moves, your next run executes new code with your secrets in the environment. In the Trivy case, as Wiz describes it, workflows that referenced the action by tag pulled the poisoned versions. CISA's alert on tj-actions/changed-files, from March 2025, describes the same pattern: a compromised action exposing secrets such as access keys and tokens in the workflow.

A full 40 character commit SHA cannot be moved. The content is fixed.

How to pin without losing updates

  1. Find the commit the tag points to today and check it against the project's release page.
  2. Replace the tag with the SHA and keep the version as a trailing comment, so humans can read it.
  3. Turn on automated update pull requests so SHAs get bumped, and review each bump like a code change.
  4. Add a check that fails the build when a workflow uses an unpinned third-party action.

What pinning does not fix

A SHA pin protects you from later tampering. It does not protect you from a malicious commit that was already there when you pinned. Pinning plus review of the diff on each update covers more. Also consider:

  • Give each job the least token permissions it needs.
  • Keep long-lived secrets out of jobs that run third-party code, and use short-lived credentials where you can.
  • Treat the action's own repository permissions and maintainers as part of your supply chain.
  • Be careful with workflows that run untrusted pull request code with elevated permissions.

Which actions to pin first

Start with any action that runs with secrets: deploy, publish and cloud login steps. Then anything that runs a scanner or setup step early in the job, since it executes before the rest and can see the environment. Actions published by your own organization are lower risk but still worth pinning.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a failed check can stop a change before it merges.

Quick check

Is pinning to a major tag like v4 enough?

No. Major tags move by design, and they can also be repointed by an attacker.

Do I need to pin first-party GitHub actions?

It is stricter and safer to pin them too, but third-party actions that handle secrets matter most.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.