Not completely. GitHub's documentation says that when you require actions to be pinned to a full-length commit SHA, reusable workflows can still be referenced by tag. So the policy checks actions but leaves a gap for shared workflows, and you need a review habit or a separate check to close it.
What the setting does
In an organization's Actions policy, you can choose to allow or block specified actions and reusable workflows, and you can turn on an option to require actions to be pinned to a full-length commit SHA. With it on, a workflow that references an action by a tag or branch is not allowed to run that step.
The same documentation adds a limit: reusable workflows can still be referenced by tag. Read that carefully. It is not a bug report, it is a stated boundary of the control, and it is easy to miss when you tell leadership that all workflow references are pinned.
Why the gap matters
A reusable workflow is not a small helper. It is a whole job definition that runs with whatever the caller passes in: permissions, secrets, and environment access. GitHub's own guidance says the same principles apply to third-party reusable workflows as to actions, because a compromise of one can be very significant.
A tag is a pointer that can be moved if the repository is compromised. If a caller references a workflow at a release tag, then moving that tag changes what runs, with the caller's secrets in scope.
Referencing options compared
| Reference | What it follows | Risk |
|---|---|---|
| Full commit SHA | One exact commit | Lowest; the code cannot change under you |
| Release tag | Whatever the tag points at | Tag can be moved or deleted |
| Branch name | The branch tip | Changes with every push |
The reusable workflow documentation lists all three as valid. It says that if a release tag and a branch share a name, the tag takes precedence, and it says using the commit SHA is the safest option for stability and security.
How to close the gap
- Use the SHA in every
usesline that points at a reusable workflow, whether internal or external. Add a comment with the human version so reviewers know what the SHA corresponds to. - For workflows in your own organization, decide whether a tag is acceptable. If a small team owns both repositories and protects the tags, the risk is lower than for outside code.
- Add a pull request check or a review rule: any new
usesline must show a SHA. Pair it with code owners on the workflows folder, so changes get a human look. See CODEOWNERS for workflow files. - Keep pinned references fresh. A pinned SHA does not update itself, and an update tool can open pull requests for you.
- Audit what exists. A one-off search across your repositories for
uses:lines that end in a tag will show where the gap is today.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate blocks a change before merge, which is the same shape as a rule that rejects an unpinned reference.
What to tell stakeholders
Say it plainly: our policy requires pinned actions, and shared workflows are covered by review, not by the setting. That statement is accurate and it invites the right follow-up, which is how reviews are enforced.
Quick check
Is a tag on a reusable workflow always unsafe?
No. For workflows in your own organization with protected tags, it can be a fair trade. For external workflows, pin to a SHA.
Does the setting block branch references to actions?
With the setting on, actions must be pinned to a full-length commit SHA, so tag and branch references to actions are not allowed.
Sources
- GitHub Docs: Disabling or limiting GitHub Actions for your organization
- GitHub Docs: Reusing workflows
- GitHub Docs: Secure use reference
Last reviewed: 19 October 2026.
