To lock down GitHub Actions on a small team, set the default token to read only, grant extra permissions per job, pin third party actions to full commit SHAs, keep secrets scoped to what each workflow needs, and require review for changes to workflow files. These are settings, not projects.
Why this comes up in questionnaires
Reviewers ask who can change your build and what the build can touch. Your pipeline can read source, hold deployment credentials and publish artifacts, so it is part of your supply chain. A clear answer about workflow settings is concrete and checkable.
The five settings
- Default token permissions. GitHub's hardening guide says it is good security practice to set the default permission for the GITHUB_TOKEN to read access for repository contents, then increase permissions for individual jobs. Do this at the organization or repository level, and add a permissions block to each workflow.
- Pin third party actions. The same guide explains that pinning an action to a full length commit SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, since they would need to produce a SHA-1 collision for a valid Git object. Tags can move; a full SHA does not. When you pin, verify the SHA comes from the action's real repository.
- Least privilege secrets. The guide notes that any user with write access to a repository can read all secrets configured in it, so credentials used in workflows should carry the minimum privileges they need. Prefer short lived credentials where your cloud provider supports them, and use separate secrets per environment.
- Review workflow changes. Protect the main branch and require review for edits under the workflows directory. A workflow file is code that runs with your permissions.
- Restrict who can approve deployments. Use environment protection rules so production deploys need a named approver.
Before and after
| Area | Typical starting point | Tighter setting |
|---|---|---|
| Token | Read and write by default | Read only, raised per job |
| Third party actions | Referenced by tag | Referenced by full SHA |
| Secrets | One shared credential | Scoped per environment |
| Workflow edits | Anyone with write access | Reviewed like production code |
| Production deploy | Automatic from any branch | Protected environment with approver |
Keep pinned actions fresh
Pinning trades convenience for control, so someone has to update the pins. Use an automated update tool to open pull requests for new versions, and review the changelog before merging. GitHub's Dependabot reference describes a cooldown option that delays version updates for a number of days, which can add a pause before adopting a brand new release. It applies to version updates, not security updates.
What to hand a reviewer
A short note, with exports: default token setting, a sample workflow with its permissions block, branch protection that covers workflow files, and the environment rules for production. Date everything.
Limits of this approach
These settings reduce risk; they do not remove it. A pinned action can still contain a flaw, and a reviewed workflow can still be wrong. Describe controls honestly and avoid saying your pipeline is "secure".
For related reading, see our guide to hardening CI/CD pipelines end to end.
Safeguard offers policies and gates that can block a pull request when a check fails, which fits alongside these settings. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is pinning to a tag good enough?
A tag can be moved by whoever controls the action repository. A full commit SHA is the stronger reference.
Will read only tokens break our builds?
Some jobs will fail at first. Add the specific permission back for that job and nothing more.
Do self hosted runners change this?
They add their own concerns, such as isolation between jobs. Check the vendor documentation for runner hardening.
Sources
Last reviewed: 19 October 2026.
