Not through Dependabot alerts. GitHub documents that Dependabot only creates alerts for vulnerable actions that use semantic versioning, and will not create alerts for actions pinned to SHA values. You can keep the pin and still get coverage by adding a version comment and an inventory that is checked against advisories.
The trade-off in one sentence
A full commit SHA gives you the strongest guarantee about what code runs. A semantic version tag gives you machine-readable version information that advisory tooling understands. GitHub's secure use guidance recommends the SHA, and also says Dependabot alerts depend on semantic versions. Both statements are true at once, so you need a plan that gets both benefits.
What GitHub says about the two Dependabot features
- Version updates open pull requests to update actions to the latest version when a new version is released.
- Security updates open pull requests to update actions with reported vulnerabilities to the minimum patched version.
- Alerts are created for vulnerable actions that use semantic versioning, and not for actions pinned to SHA values.
- Locally referenced actions and reusable workflows are ignored.
So a SHA-pinned action may be vulnerable with no alert on it. The risk is silence, not an error.
Closing the gap
- Pin to the SHA and keep the version in a comment on the same line, for example a trailing comment that names the release the SHA corresponds to. Reviewers can read it, and update tools can use it to propose bumps.
- Run version updates for actions on a schedule so pinned references move forward through reviewed pull requests, rather than staying frozen for a year.
- Use dependency review on pull requests. GitHub describes it as a way to see added or updated actions and their known vulnerabilities, so a new action is checked when it is introduced.
- Keep your own inventory. A list of every action, its owner, the pinned SHA and the human version lets you answer an advisory question in minutes. Without it you will be searching repositories under pressure.
- Subscribe to advisories for the actions you rely on, and for the ones whose maintainers publish them, watch the repository releases.
- For actions inside shared or local workflows, remember local references are not covered by Dependabot, so cover them in review.
What to put in the inventory
| Field | Why |
|---|---|
| Action name and owner | Matches advisories to the right repository |
| Pinned SHA | The exact code that runs |
| Human version | Lets you compare with advisory ranges |
| Jobs and repositories that use it | Tells you where to patch |
| Permissions and secrets in those jobs | Sets the urgency |
Try it yourself
Click through it at your own pace, or open it full screen. See how a single list turns a vague worry about a package into a concrete set of places to fix.
Related reading
For the pinning question itself, see should you pin GitHub Actions to a commit SHA, and for how actions show up in a bill of materials, GitHub Actions in your SBOM.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning and policy gates, which can help you keep an inventory and block changes that add components you have not approved. A free scan is available at gold.safeguard.sh/scan.
Quick check
Should I stop pinning to SHAs to get alerts?
No. Pinning protects you from a moved tag. Keep it, and add the version comment, scheduled updates and an inventory to cover the alert gap.
Does dependency review help with actions?
GitHub says it shows added or updated actions and their known vulnerabilities on pull requests, so it is a useful check at the point of change.
Sources
Last reviewed: 19 October 2026.
