Use Dependabot version updates with the github-actions ecosystem. It opens a pull request when a pinned action has a new release, and it updates the version comment on the same line as the SHA. You review each pull request like a new dependency instead of leaving old versions in place for years.
The tension with pinning
Pinning actions to a full length commit SHA is what GitHub recommends for repositories that do not use its workflow dependency lockfiles, because a tag can be moved but a commit cannot. The cost is that nothing updates by itself. Left alone, pins go stale, and stale actions miss fixes.
The answer is not to unpin. It is to automate the proposal and keep the human review.
Set up Dependabot for actions
GitHub's documentation gives these steps:
- Create
.github/dependabot.ymlin the repository. - Add an entry with package-ecosystem set to github-actions.
- Set directory to the repository root, which covers
.github/workflows. - Choose a schedule interval, such as weekly.
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
What Dependabot handles and what it does not
| Case | Behaviour per GitHub docs |
|---|---|
| Action pinned to a SHA with a tag comment on the same line | Updates the SHA and the comment |
| Action pinned to a commit not tied to any tag | Updates to the latest commit, which may differ from the latest release |
| Local actions in the same repository | Ignored |
| Docker container actions using docker:// | Not supported |
There are two related features. Version updates open pull requests for new releases. Security updates open pull requests for actions with reported vulnerabilities, moving to the minimum patched version.
How to review an update pull request
Do not merge on green alone. Take two minutes:
- Read the release notes and the diff between the old and new SHA.
- Check the new SHA is in the action's own repository.
- Look for new network calls, new inputs or changed permissions.
- Merge only if the change matches what the release notes say.
If the action is critical and the diff is large, hold the update for a day and see whether the community reports problems.
Enforce the pin
An organization policy can require pinning. GitHub's docs describe an option to require actions to be pinned to a full length commit SHA, which applies to your own organization's actions and to actions authored by GitHub, though reusable workflows can still be referenced by tag. Combine it with Dependabot so that enforcement does not create a backlog.
Watch for drift
Run a check that counts workflow references not pinned to a SHA. A weekly count that trends to zero is a good habit. For the pinning step itself, see our post on pinning actions to SHAs correctly.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's continuous monitoring rescans projects as new advisories appear, so a pinned dependency that becomes risky after release is flagged without waiting for the next build. Workflow action references are a GitHub setting to enforce.
Quick check
Does Dependabot work on private repositories?
GitHub's docs say Dependabot supports both public and private repositories for GitHub Actions.
How often should I update actions?
Weekly is a common starting point. Pick a rhythm your team will actually review.
Sources
- Keeping your actions up to date with Dependabot, GitHub Docs
- Secure use reference, GitHub Docs
- Disabling or limiting GitHub Actions for your organization, GitHub Docs
Last reviewed: 19 October 2026.
