Yes, for any third party action in a workflow that runs on pull requests. A tag can be moved to different code, but a full length commit SHA cannot be changed without a hash collision. Pinning means the action you reviewed is the action that runs, on every outside contributor's pull request.
Why this matters more on pull request workflows
Pull request workflows run often and process untrusted code. An action used in them executes inside your job, with access to the token and anything on the runner. If its tag is repointed to malicious code, every run picks it up. GitHub's secure use guidance says pinning to a full length commit SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, because they would need to produce a SHA-1 collision for a valid Git object.
The same page notes a stronger option for repositories that can adopt it: workflow dependency lockfiles, which record the exact commit for every action including transitive dependencies and verify the source at run time.
Definition
A tag such as v4 is a movable label. A commit SHA is the identifier of one exact commit. Pinning replaces the label with the identifier.
# movable
- uses: actions/checkout@v4
# pinned, with the human readable version in a comment
- uses: actions/checkout@<full 40 character commit SHA> # v4.x.y
Steps
- List every uses line across your workflow files, including those inside composite actions.
- For each third party action, open its repository and pick the commit of the release you reviewed.
- Verify the SHA comes from the action's own repository and not from a fork. GitHub specifically advises this check.
- Replace the tag with the full SHA and keep a comment with the version.
- Enable an automated updater for actions, so pins move forward through reviewed pull requests.
- Add a CODEOWNERS rule so changes to uses lines get a human review.
Trade offs
| Choice | Benefit | Cost |
|---|---|---|
| Tag alone | Easy updates | Silent changes possible |
| Full SHA pin | Immutable reference | Updates need a pull request |
| Lockfile | Covers transitive actions | Needs adoption of the lockfile feature |
| Fewer actions | Smaller attack surface | Write more shell yourself |
Also reduce how many third party actions you use. A simple shell step you can read beats an action you cannot audit.
What about actions from your own organization?
Pin them too if they are used in public repositories or reachable by outside pull requests. Internal references can use tags if trusted people alone can edit the called repository, but SHA pinning is still a cheap habit.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the inventory view. A list of every third party component is the first step toward pinning them all.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation give you the inventory of what you consume, and policies can flag changes. Try the free scan.
Quick check
Does a SHA pin protect against a bug in the pinned version?
No. It fixes which code runs and nothing more. You still need to review and update it.
Why check that the SHA is not from a fork?
A fork can contain a commit with the same name in its history. GitHub advises verifying the SHA belongs to the action's own repository.
Sources
Last reviewed: 19 October 2026.
