A Practical GitHub Workflow Security Checklist Before You Merge
A short GitHub workflow security checklist covering SHA pinning, token permissions, event triggers, secrets, and review boundaries.
If your team reviews application code carefully but barely looks at .github/workflows, this checklist is the simplest place to improve.
Use it whenever a workflow is added or changed.
GitHub workflow security checklist
1. Are third-party actions pinned to full SHAs?
If not, ask why. Mutable tags are one of the most common supply-chain weaknesses in GitHub Actions.
2. Are token permissions explicitly scoped?
Look for a top-level or job-level permissions: block. If a workflow relies on broad defaults or write access everywhere, it needs a tighter model.
3. Does the workflow use pull_request_target?
If yes, review it carefully. Check whether it executes pull request code, touches secrets, or mixes privilege with untrusted inputs.
4. Are secrets used only where necessary?
Secrets should live in the smallest possible scope. Avoid exposing them to jobs that do not need them, especially validation paths triggered by contributors.
5. Does any run: step interpolate attacker-controlled values?
Titles, branch names, issue bodies, and pull request metadata can all become unsafe if pushed directly into the shell.
6. Are deployment or release jobs isolated from test jobs?
Trusted and untrusted execution paths should not be mixed casually in the same workflow.
7. Is cloud access using OIDC instead of long-lived static secrets?
For teams deploying to cloud providers, this is often one of the best medium-term upgrades.
8. Will this workflow be easy to maintain securely?
A workflow that works today but is hard to review tomorrow will drift. Prefer patterns that are explicit, narrow, and easy for another engineer to understand later.
How to use this checklist in practice
Do not turn this into a giant process document. Keep it attached to ordinary engineering workflow:
- reviewers use it during pull requests
- scanners flag violations automatically
- fix PRs handle the deterministic cases
- policy blocks only the highest-risk regressions
That keeps security enforcement proportional to team size.
What to prioritize first
If you are triaging an existing backlog, start with:
- unpinned third-party actions
- broad write permissions
- unsafe
pull_request_targetusage - release and deployment workflows
That order gives most teams the fastest improvement.
Bottom line
Good GitHub workflow security is not about reviewing every line with paranoia. It is about consistently catching the handful of patterns that create the most risk.
If your team can apply this checklist before merge, workflow security becomes manageable instead of invisible.
Apply this checklist to your repositories
Use action pin to find unpinned actions, broad token permissions, risky pull request triggers, and workflow security issues before they merge.
Related Guides
Keep hardening GitHub Actions
Learn the GitHub Actions security best practices that reduce supply-chain risk without turning your small team into a DevSecOps department.
Most workflows do not need broad write access. This guide shows how to trim GitHub Actions permissions step by step.
A practical rollout plan for SHA pinning in GitHub Actions, including what to pin first and how to handle updates safely.