How do you pin GitHub Actions to a SHA without falling behind?

Pin each action to a full-length commit SHA, then let Dependabot open pull requests when new versions appear. GitHub's guidance says SHA pinning helps mitigate a backdoor added to the action's repository. The pin alone is not enough, though, because a frozen pin never receives fixes unless something updates it.

Why pin at all

A tag such as v4 can be moved by whoever controls the action's repository. A commit SHA cannot. GitHub's secure use guide says to pin references to actions to a commit SHA in your workflow files, which helps reduce the risk of a bad actor adding a backdoor to the action.

Two cautions from the same page. First, verify the SHA comes from the action's own repository and not from a fork. Second, the page says a lockfile, where a repository adopts one, is the strongest protection and supersedes SHA pinning.

The cost of pinning

A pinned SHA is a snapshot. If the action later fixes a bug or a security issue, your workflow keeps running the old code. Left alone, pins turn into a quiet backlog of outdated build steps.

The guide also notes a gap: Dependabot will not create alerts for actions pinned to SHA values. So the alert channel goes quiet exactly when you adopt the stronger practice. You need the other channel, version updates.

Keeping pins fresh

The guide says Dependabot version updates open pull requests to update actions to the latest version when a new version is released. Dependabot security updates open pull requests for actions with reported vulnerabilities, moving to the minimum patched version. The supported ecosystems list includes github-actions.

A minimal configuration looks like this:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

A review habit that works

1. Pin every third-party action to a full SHA, with a comment showing the version it matches.
2. Enable Dependabot version updates for github-actions on a weekly schedule.
3. Review each update pull request: read the release notes and the diff between SHAs.
4. Merge quickly. A pull request that sits for months defeats the point.
5. Treat actions from your own organization the same way, since they change too.

What to scrutinize in an update

Check who changed the code, what permissions the action requests, and whether it started downloading or running new things. A version bump that adds a network call deserves a question before it merges.

Safeguard's pull request gates and policies can enforce checks on workflow changes before they reach your main branch. You can try a free scan at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen.

Watch how a pull request gets checked before merge, the same place an action update pull request should be reviewed.

Quick check

Sources

• GitHub Actions secure use reference
• Dependabot supported ecosystems

Last reviewed: 19 October 2026.