For many repositories, Dependabot alerts already act as an event-driven scan: they fire when a new advisory is added or your dependencies change. They do not replace everything. They cover dependencies GitHub understands, from advisories GitHub has reviewed, and they will not scan your container images or other sources.
What the documentation says
According to GitHub's Dependabot alerts documentation:
- When a new vulnerability is added to the GitHub Advisory Database, Dependabot scans the default branch and sends an alert for affected repositories.
- When your dependency graph changes, it also checks and can alert.
- New vulnerabilities may take time to appear in the database, so alerts can be delayed.
- Only advisories reviewed by GitHub trigger alerts.
- Notifications go by email to users with write, maintain or admin access who watch the repository, with an option for a weekly digest.
What that means in practice
| Need | Covered by alerts? |
|---|---|
| New advisory against a manifest in the default branch | Yes |
| Newly added vulnerable dependency | Yes |
| Release branches and older supported versions | Not by default branch scanning |
| Container image contents | Not by this feature |
| Software in other source hosts | No |
| Your own policy, such as licenses or age of package | No |
| One cross repository view with owners and SLAs | Limited |
Steps to decide
- List where your code and artifacts live. If everything is on one platform and is mostly packages, alerts get you a long way.
- Check release branches. If you support older versions, you need another way to scan them.
- Check images and infrastructure files. They need their own scanners.
- Decide who reads the alerts. An email to individual watchers is not a process. Route them to a queue with owners.
- Add a scheduled job only where a gap remains. Do not run two overlapping systems that raise the same alert twice.
Security updates versus version updates
Dependabot also opens pull requests. GitHub's options reference says version updates run on a schedule you set, and that security updates are separate: the cooldown option does not apply to them, and they have their own fixed limit of 10 open pull requests (options reference). So a quiet schedule for routine upgrades does not slow urgent fixes.
Quick check
Do alerts fire for existing vulnerabilities when I enable them?
Alerts are created for what is found at enablement, but the documentation says you receive notifications only for vulnerabilities identified afterward.
Is the default branch enough?
For the code you ship from it, yes. For supported older versions, no.
Sources
Last reviewed: 19 October 2026.
