Pinning and Trusting Third-Party Actions
A uses: line is curl | bash for your CI, so know exactly what you are running.
Every uses: some/action@v3 in your workflow runs third-party code with access to your repository and token. A moving tag like @v3 can be repointed to malicious code at any time. This lesson covers pinning actions to an immutable commit SHA, vetting what you depend on, and keeping pins current.
The risk of a moving tag
Tags like @v3 and branches like @main are mutable: the maintainer (or an attacker who compromises the account) can repoint them to new code. Your next run would execute that new code with your token and secrets. Pinning to a specific commit SHA freezes exactly the code you reviewed.
Pin to a full commit SHA
Replace the tag with the full 40-character commit SHA, and keep the human-readable version in a trailing comment.
steps:
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
- uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0 # v6.0.0Vet before you trust
- Prefer actions from verified creators or those you can read the source of.
- Check that the action is actively maintained and widely used.
- Minimize the number of third-party actions; fewer dependencies means less attack surface.
- Combine pinning with a least-privilege
GITHUB_TOKENso even a bad action is contained.
Keep pins current
Pinning to a SHA is not "set and forget": you must update pins to get security fixes. Use Dependabot's GitHub Actions ecosystem to open pull requests that bump pinned SHAs, so you stay current without giving up immutability.
Key takeaways
- Moving tags can be repointed to malicious code; pin actions to a full commit SHA.
- Vet third-party actions and minimize how many you depend on.
- Use Dependabot to keep pinned SHAs updated for security fixes without losing immutability.