Start with three organization settings under Settings, Actions, General: limit which actions can run, require actions to be pinned to a full commit SHA, and set the default GITHUB_TOKEN to read only. Together they shrink the blast radius of a compromised action without touching every repository.
The three settings
| Setting | What it does | Watch out for |
|---|---|---|
| Limit allowed actions | Allow your org plus selected actions and reusable workflows, with wildcards | List holds up to 1,000 entries; allowing solely your org also blocks GitHub authored actions such as checkout |
| Require full length SHA pinning | Every action must be pinned to a commit SHA, including GitHub authored ones | Reusable workflows can still be referenced by tag |
| Default workflow permissions | Restricted gives read access to contents and packages | Workflows can still raise it with a permissions key |
These details come from the GitHub documentation on limiting Actions for an organization. New organizations start with the restricted token setting, but older ones may still be permissive, so check.
Why these three
Tags can be moved or deleted, which is why the GitHub hardening guide advises pinning to a commit SHA and verifying the SHA comes from the action's own repository, not a fork. A read only default token means a compromised step cannot push code or edit releases unless the job asked for that permission.
The same guide suggests considering a block on workflows creating or approving pull requests, since that can let a change merge without proper oversight.
Rollout steps
- Export a list of actions in use across the org. A code search for
uses:is a start. - Add the commonly used, trusted ones to the allow list.
- Turn on SHA pinning in a pilot period, and run a bot that rewrites tags to SHAs.
- Switch the default token to restricted. Expect some workflows to fail until they declare
permissions. - Publish a short migration note with a copy and paste
permissionsblock.
Caveats
If an enterprise policy overrides your organization, you may not be able to change these. Also, settings stop casual drift but not intent: a repository admin can still write a permissive permissions block. Pair settings with code review on workflow files, for example a CODEOWNERS entry for .github/workflows.
Quick check
Will SHA pinning break our existing workflows?
Yes, any workflow using a tag or branch reference for an action will fail once enforcement is on. Rewrite references first and use a bot to keep them updated.
Does a read only default token stop all abuse?
No. It limits what a step can do by default. A job can still request more, so review workflow changes.
Safeguard provides dependency scanning and policy gates for pipelines, and you can try the free scan at gold.safeguard.sh/scan.
Sources
- GitHub Docs: Disabling or limiting GitHub Actions for your organization, fetched 19 October 2026
- GitHub Docs: Security hardening for GitHub Actions, fetched 19 October 2026
Last reviewed: 19 October 2026.
