Dependabot alerts tell you when a dependency in your repository has a known vulnerability, and link to a fixed version when one exists. They are a good free baseline for a small team, but they only cover reviewed advisories and do not tell you whether the vulnerable code is actually used. Pair them with a weekly triage routine.
What the alerts do
GitHub's documentation says alerts flag vulnerable dependencies so you can upgrade, with the affected file, a description, the severity and a fixed version when available. They appear in the security tab and in the dependency graph, and can be assigned to people.
Alerts are generated for the default branch in two cases: a new vulnerability is added to the GitHub Advisory Database, or your dependency graph changes, for example when a commit updates a package.
What they miss
GitHub states that only advisories reviewed by GitHub trigger alerts, and new vulnerabilities may take time to appear in the database. Alerts cannot catch every issue, so keep manifest and lock files current. Archived repositories are not scanned. For GitHub Actions, only actions using semantic versioning generate alerts, not those pinned to a commit SHA.
They also say nothing about reachability. A vulnerable function you never call is lower priority than one on your request path.
A weekly routine for a small team
- Pick a fixed 30 minute slot and one owner for the week.
- Sort open alerts by severity, then by whether the package is in a production path.
- Fix the easy ones: patch or minor bumps with passing tests.
- For breaking upgrades, create a ticket with a date.
- Dismiss with a reason when a vulnerable code path is not used. The reason is the useful part.
- Record what changed, for your questionnaire answers.
Auto triage rules can dismiss low risk alerts before notifications, which helps against noise. Write the rule down so the team knows what is hidden.
Alert fatigue is the real risk
Teams that get fifty alerts a week and no process end up ignoring all of them. Fewer, prioritised, owned alerts beat a long list. Set a service level you can keep, such as critical in production within a week.
Going beyond alerts
If you want reachability analysis and fix pull requests that you approve, Safeguard offers SBOM and dependency scanning and reachability analysis. Autonomous remediation is off by default, with every category set to Manual. You can see a dependency inventory in this demo.
Click through it at your own pace, or open it full screen.
Common pitfalls
Common mistakes: enabling alerts and never assigning an owner, turning on automatic dismissal without writing down the rules, and treating a count of zero as proof of safety. A zero only means no reviewed advisory matches the dependencies GitHub can see. Packages vendored into the repository, system packages inside container images and unpinned transitive dependencies may sit outside what alerts show, so keep a second look at those, for example during image builds.
Quick check
Do we need to enable anything for alerts?
Repository administrators and organization owners can enable them, per GitHub's documentation.
Sources
Last reviewed: 19 October 2026.
