Pin GitHub Actions by Commit
Replace mutable GitHub Action tags with reviewed commit IDs and keep an owner and update path for each pinned action.
A workflow that uses some-action@v3 follows a tag that the action publisher can move. A reviewed commit ID identifies the action code the workflow is meant to run. GitHub's secure-use guidance recommends pinning actions to full-length commit SHAs for stronger immutability. This does not make the action harmless; it makes the reviewed version stable.
Inventory every uses: reference in the release workflows, including reusable workflows. Distinguish first-party actions, third-party actions, Docker images, and local actions. Do not pin only the most visible build job while a deployment job still uses a mutable reference.
Action pin record
| Field | Entry |
|---|---|
| Workflow and job | Where the action runs |
| Repository | Exact action owner and name |
| Reviewed tag | Human-readable release at review time |
| Full commit SHA | Immutable reference placed in workflow |
| Permissions | Token and secrets available to the job |
| Owner | Person who approves updates |
| Update trigger | New release, advisory, or policy review |
Resolve the tag to a commit from the action's trusted repository. Review release notes and the diff from the prior pinned commit. Change the workflow to the full SHA, with a comment that names the release for maintainers. Keep the update process active; a pin left unchanged forever can miss security fixes.
Test the workflow boundary
In an owned repository, run the pinned workflow on a harmless fixture. Confirm the job uses the expected commit and still produces the intended artifact. Then change only the pinned SHA in a review branch and inspect the exact code difference before merging. A workflow should not run untrusted pull-request code with a write-capable token just because its actions are pinned.
Record the workflow commit, action SHA, reviewer, and test result. If a referenced action has no clear source or owner, hold it for replacement rather than inventing a trust claim. Pinning protects against silent tag movement, but job permissions, secret exposure, and build provenance remain separate controls.
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