Because alerts depend on advisory data, not only on your commits. GitHub documents that Dependabot sends alerts when a new vulnerability is added to the GitHub Advisory Database, or when your dependency graph changes. The package did not change. What was known about it did.
The two triggers
The Dependabot alerts documentation says it scans a repository's default branch and sends alerts when:
- A new vulnerability is added to the GitHub Advisory Database.
- Your dependency graph changes, for example when you push commits that update packages or versions.
The first trigger explains your surprise. A library you installed two years ago can acquire an advisory today, because a researcher found a flaw or a maintainer published a record. You get an alert although nobody touched the repository.
What this tells you
An alert is a statement about knowledge, not about a change in your code. It means "something about the version you run is now publicly known to be a problem". The risk may have existed all along. The difference is that you now have a record to act on.
This is why repositories that are "done" and untouched still collect alerts. Quiet code is not safe code.
What to do with the alert
- Read the alert detail. Each alert includes the advisory, severity and, where available, the patched version.
- Check whether it is a direct or transitive dependency.
- See whether Dependabot has proposed an update pull request. If so, review and test it.
- If there is no fix, follow your exceptions process. Our guide on advisories with no patched version lays out options.
- Assign an owner. GitHub's documentation says users with write access or higher can assign alerts to collaborators or teams, which makes responsibility visible.
Reduce surprise
Stale alerts pile up because nobody owns the repository. Three habits help:
- Keep a list of repositories and a named owner for each.
- Review alerts on a schedule, such as weekly, not only when someone remembers.
- Retire repositories you no longer need. An archived project can still hold alerts and confuse reviewers.
Alerts are only on the default branch
Because the scan covers the default branch, a vulnerable dependency on a long running feature branch or a release branch may not appear. If you ship from release branches, check how you cover them.
What alerts do not say
They do not say whether the vulnerable function is called in your code. They do not say whether an attacker can reach it. That needs reachability or an exploitability check, which you can do manually for a few findings and need tooling for hundreds.
Where Safeguard fits
Safeguard keeps your SBOM and dependency inventory current, so new advisories are matched to what you run, with reachability analysis to help rank them. 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.
Look at how every component is listed with its version, which is what an advisory is matched against.
Quick check
Do I need to push a commit to get an alert?
No. A new advisory in the database can trigger one on its own.
Does a quiet alert list mean my code is safe?
No. It means no known advisory matches the default branch right now.
Sources
Last reviewed: 19 October 2026.
