Per GitHub's security guidance, a workflow dependency lockfile is the strongest protection, a full-length commit SHA is the fallback where you cannot adopt one, and a tag is acceptable only for creators you trust. A tag can be moved or deleted, so it is not a fixed reference.
Three options, ranked by GitHub
GitHub's hardening guide says the best measure is to lock workflow dependencies with a lockfile. It records the exact commit for every action your workflows depend on, including transitive dependencies, and verifies the identity of each source repository at run time. The guide calls this the strongest protection available and says it supersedes SHA pinning for repositories that adopt it.
| Option | What it fixes | Weakness |
|---|---|---|
| Workflow lockfile | Every action and its transitive dependencies | Needs adoption in the repository |
| Full-length commit SHA | The action's own code at one commit | Does not cover what the action pulls in |
| Tag | Nothing firmly | Tags can be moved or deleted |
Why SHA pinning helps
The guide says pinning to a full-length commit SHA mitigates the risk of a bad actor adding a backdoor to the action's repository, because they would need to generate a SHA-1 collision for a valid Git object payload. It also tells you to verify that the SHA comes from the action's repository and not from a fork.
steps:
- uses: owner/action@0123456789abcdef0123456789abcdef01234567
That value is a placeholder. Use the real commit you have reviewed, and add a comment with the human readable version so reviewers can follow it.
Why tags are weaker
The guide says to pin to a tag only if you trust the creator. Even then there is risk, because a tag can be moved or deleted if a bad actor gains access to the repository. The Verified creator badge on the marketplace is described as a useful signal that the author's identity was verified. It does not say the code is safe.
A decision guide
- If your repository can adopt a lockfile, use it. It covers transitive dependencies too.
- If not, pin every third-party action to a reviewed full commit SHA.
- Allow tags only for actions from creators you trust, and review the action's source regardless.
- Treat reusable workflows from other repositories the same way as actions.
- Update pins through reviewed pull requests, so an update is a visible decision.
What pinning does not do
Pinning stops an action from changing under you. It does not make the action well behaved. The guide notes that a compromise of a single action can be very significant, since jobs in a workflow can affect each other and the action could reach secrets and the repository token. So audit the source, limit token permissions, and keep secrets out of jobs that do not need them.
GitHub also points to code scanning for workflows and to OpenSSF Scorecards for spotting risky workflow patterns.
Where Safeguard fits
Safeguard offers policies, gates and guardrails for pull requests, and dependency scanning and SBOM generation. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Open the demo and see how a pull request gate stops a change until it is reviewed, the same idea as reviewing a pin update.
Click through it at your own pace, or open it full screen.
Quick check
Is a commit SHA always safer than a tag?
GitHub says SHA pinning mitigates a backdoor in the action repository, since a collision would be needed. Verify the SHA is from the real repository and not a fork.
Does pinning make an action trustworthy?
No. It stops the action from changing. You still need to audit its source and limit what it can access.
Sources
Last reviewed: 19 October 2026.
