A missing Dependabot alert usually has one of a few causes. The advisory may not be reviewed by GitHub, the ecosystem or file may be unsupported, the repository may be archived, the package may not be in the dependency graph, or the alert predates when you enabled alerts. Check each in turn.
How alerts are produced
Dependabot builds a dependency graph from your repository's manifest and lock files and scans the default branch. It matches those dependencies against the GitHub Advisory Database. Alerts appear in the Security tab and in the dependency graph, with severity and a fixed version when one exists.
Cause 1: the advisory is not reviewed
The documentation says only advisories reviewed by GitHub trigger alerts. A vulnerability that exists only as an unreviewed record will not produce one. New vulnerabilities also take time to appear in the database.
Cause 2: the package is not in the graph
If the ecosystem or manifest type is unsupported, or a lock file is missing, the dependency may not be recorded. No graph entry means no alert.
Cause 3: archived repository
Archived repositories are not scanned.
Cause 4: GitHub Actions pinned to a SHA
For GitHub Actions, only actions that use semantic versioning generate alerts, not those pinned to commit SHAs. SHA pinning is still a good practice, but it means you need another way to learn about problems in those actions.
Cause 5: notification timing
When alerts are first enabled, GitHub generates the graph and creates alerts for existing vulnerable dependencies. Notifications, however, cover only vulnerabilities identified after you enable them. You may have alerts in the tab that never emailed you.
Cause 6: auto-triage rules
Auto-triage rules can dismiss low risk alerts before notifications are sent. If a rule is too broad, real alerts may be hidden. Review the closed alerts list once.
A diagnosis table
| Symptom | Likely cause | Fix |
|---|---|---|
| Package absent from dependency graph | Unsupported file or no lock file | Commit lock files, use submission API |
| Advisory exists elsewhere, no alert | Not reviewed by GitHub | Track it manually |
| No alert on an action | Pinned to SHA | Add a separate check |
| No email, alert in tab | Notified only after enablement | Check notification settings |
| Repo untouched | Archived | Unarchive or scan elsewhere |
Another gap to keep in mind
The alerts page does not describe reachability or call graph analysis, so an alert says a vulnerable version is present, not that vulnerable code is called. That cuts both ways: you can get alerts you could safely defer, and the quiet ones are not proof of safety.
Where a dedicated scanner fits
A second source helps when you suspect gaps. Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan lets you compare the results.
Try it yourself
Click through it at your own pace, or open it full screen.
See how many findings remain once you ask whether the vulnerable code is actually called.
Quick check
Do alerts cover every ecosystem?
No. Coverage is limited to supported ecosystems listed in GitHub's reference.
Will a SHA pinned action raise an alert?
According to the documentation, no. Only actions using semantic versioning generate alerts.
Sources
Last reviewed: 19 October 2026.
