On GitHub, enable Dependabot alerts in the repository's security settings. GitHub then checks your dependencies against its advisory database and notifies maintainers when a vulnerable library appears. For a volunteer team, the real work is deciding who receives alerts and how to keep the volume manageable.
What the alerts do
GitHub's documentation says Dependabot scans a repository's default branch and sends alerts in two cases: a new vulnerability is added to the GitHub Advisory Database, or your dependency graph changes. That second case matters, because adding a library can bring in a known flaw on day one.
An alert is not a fix. It tells you which package, which advisory and which version to move to. A person still has to read it, test the upgrade and merge.
Turn it on
- Open the repository on GitHub and go to Settings.
- Find the security section and look for Dependabot alerts.
- Enable the alerts. Confirm that the dependency graph is on, since alerts rely on it.
- Open the Security tab afterward to see the list.
Menu names change over time, so follow GitHub's current documentation if the labels differ.
Decide who gets the email
By default, the documentation says GitHub emails people who have write, maintain or admin permissions to the repository and who are watching it with security alerts or all activity enabled. In a volunteer team, that can mean nobody sees them, because volunteers rarely watch repositories.
Do this:
- Name one owner for alerts each month, even if it rotates.
- Ask that person to watch the repository for security alerts.
- Send a copy to a shared mailbox if your setup allows it.
Handle the first flood
The documentation says that when Dependabot is first enabled, GitHub does not send notifications for every vulnerable dependency already present. It notifies for new ones found afterward, subject to your notification preferences. So check the Security tab yourself on day one.
To limit noise, GitHub recommends auto triage rules to dismiss low risk alerts, applied before notifications are sent. You can also choose a weekly email digest, or turn notifications off while keeping alerts enabled.
Decide what to fix first
| Question | If yes |
|---|---|
| Is the vulnerable code reachable in our app? | Fix soon |
| Is it a dev only package? | Lower priority |
| Is a patched version available? | Plan the upgrade |
| Is the project exposed to the internet? | Raise priority |
Not every alert is exploitable in your app. Reachability analysis asks whether your code actually calls the vulnerable function. See our post on which vulnerable dependencies matter first.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how direct and indirect packages are listed, since alerts often point at the indirect ones.
Where Safeguard fits
If you want a second view beyond one platform, Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.
Quick check
Do alerts cost money?
Check GitHub's current plan details for your repository type. This post does not state pricing.
Will alerts open fix pull requests for me?
Alerts only notify. Separate settings can propose updates, and a human should still review them.
Sources
Last reviewed: 19 October 2026.
