An alert needs three things: a reviewed advisory in the GitHub Advisory Database, a dependency on your default branch that appears in the dependency graph, and a version inside the affected range. If any is missing, no alert appears, even when the package is vulnerable in practice.
What GitHub documents
The Dependabot alerts documentation says alerts come from two inputs, the GitHub Advisory Database and your repository's dependency graph. An alert is triggered when a new vulnerability is added to the database, or when your dependency graph changes.
It then lists limits:
- Reviewed advisories only. Unreviewed advisories do not generate alerts.
- Default branch. Dependabot scans the default branch.
- Advisory lag. New vulnerabilities may take time to appear in the database and trigger alerts.
- Archived repositories are not scanned.
- GitHub Actions. Alerts come only for actions using semantic versioning, not SHA versioning.
- Existing alerts at enablement do not send notifications.
The page also says alerts cannot catch every security issue and that manifests and lock files should be kept current.
A checklist for a missing alert
| Check | How |
|---|---|
| Is the advisory reviewed? | Open it in the advisory database and look for the reviewed label |
| Is it in the right ecosystem and package name? | Compare the record with your manifest |
| Is the version in range? | Read the affected range and your resolved version |
| Is the file on the default branch? | Check where the manifest or lockfile lives |
| Does the graph include it? | Look at the repository dependency graph |
| Is it a SHA pinned action? | See the limit above |
If the advisory exists elsewhere, for example in OSV or a vendor notice, but is unreviewed on GitHub, that explains the gap. See GitHub advisory database reviewed, unreviewed and malware records.
What to do about it
- Do not wait for an alert if you have a credible report. Check your version by hand.
- Add a second source of advisory data to your process so one database's review queue does not decide your coverage.
- Scan on a schedule and on pull requests, not only when the graph changes. New advisories arrive without any change in your repository. See scheduled or event driven scans.
None of this is a criticism of the feature. Every advisory pipeline has a review step and a delay, and a good process plans for both.
Safeguard's continuous monitoring rescans stored inventory when new advisories land, and the free scan at https://gold.safeguard.sh/scan lets you compare results.
Try it yourself
Open the continuous monitoring demo and watch how a new advisory is matched to an existing inventory without a code change.
Click through it at your own pace, or open it full screen.
Quick check
Do unreviewed advisories create Dependabot alerts?
No. GitHub documents that only reviewed advisories generate alerts.
Does Dependabot scan feature branches?
The documentation says it scans the default branch.
Sources
Last reviewed: 19 October 2026.
