Minimize GitHub Actions Token Permissions
Give each GitHub Actions job only the token permissions it needs, with reviewed write exceptions and negative tests.
The automatic GITHUB_TOKEN can read or change repository resources according to workflow permissions. A test job that only checks code should not have the same write access as a release job. GitHub's secure-use reference recommends least privilege and says job-level permissions can increase from a read-only default when needed.
List workflows by trigger and trust level. A pull request from an untrusted branch, a protected-branch build, and a manually approved deployment have different authority needs. Do not decide permissions from the workflow name; inspect every API action and third-party action that runs.
Permission matrix
| Job | Needed capability | Token policy |
|---|---|---|
| Lint and unit tests | Read source | contents: read only |
| Dependency report | Read metadata | Specific read grants |
| Release tag | Create approved tag | Narrow write grant in protected job |
| Package publish | Attest and upload artifact | Explicit grants with environment gate |
| External contribution | Build untrusted code | No deployment secret or write token |
Set a restrictive workflow default and add only the permissions each job needs. A third-party action may use github.token even if the workflow does not pass it as an input. Review action code and its network behavior before giving it a write-capable job. Keep secrets in a separate release environment when the platform supports it.
Negative permission test
Use an owned repository fixture. Run a read-only job and make a harmless API request that would require write permission. It must fail. Run the protected release job and confirm its intended write succeeds after approval. Check a pull-request run separately; it must not inherit the release job's token or secret context.
Record the workflow commit, trigger, effective permission set, and test result without logging token values. A green CI run does not prove the token is narrow unless the forbidden action was tested. Revisit the matrix when workflows add new APIs or when an action is updated. Pinning an action by commit and limiting its token are complementary controls, not substitutes.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.
Sources
- GitHub Actions Secure Use ReferenceAccessed
- OpenSSF Scorecard ChecksAccessed