What Is a Dependabot Alert? Which Ones Matter
Dependabot alerts are free, noisy, and have four blind spots nobody mentions. Knowing where they cannot see is what makes the list workable.
A Dependabot alert is GitHub telling you that a package your project depends on has a known vulnerability, and usually which version fixes it. It is free, it is noisy, and it has blind spots that nobody mentions when they tell you to turn it on. Knowing where it cannot see is what turns the alert list from a source of guilt into something you can work through in twenty minutes.
Where the alert comes from
Two events produce an alert, according to GitHub's documentation on Dependabot alerts. The first is that "a new vulnerability is added to the GitHub Advisory Database" and matches something you already depend on. The second is that your dependency graph changes, for example when a commit updates packages or versions, and the new state matches an advisory already on file.
So the mechanism is a join between two lists: the packages your repository declares, and the advisories GitHub has reviewed. Each alert carries details about the vulnerability and its severity, a link to the affected file, and a fixed version where one exists.
That is the whole thing. It is not a scan of your running application, and it does not analyse your code.
The four blind spots
This is the part worth reading twice, because each of these is a place where a clean alert list means nothing.
It reads the default branch. Dependabot scans the default branch. A vulnerable dependency living on a long-lived feature branch, or in a deployment that tracks something other than the default branch, is invisible.
It only knows reviewed advisories. GitHub states that only advisories it has reviewed trigger alerts. A vulnerability published this morning will produce an alert when it has been through that process, which is not instant. The documentation is direct about the general limit: alerts "can't catch every security issue."
It depends on your manifest and lock files being accurate. GitHub's own advice is to keep "manifest and lock files up to date for accurate detection." A dependency installed outside the manifest, vendored into the repository by hand, or pulled in by a build script will not appear in the dependency graph, and what is not in the graph does not get alerted on.
Archived repositories are not scanned, and Actions are only partly covered. For GitHub Actions, alerts cover only actions referenced by semantic version, not by commit SHA. Pinning an action to a SHA is the more secure practice, and it is also the practice that silences this particular alert. Both facts are true at once, which is awkward and worth knowing.
Triage by reachability, not by severity colour
The standard advice is to work highest severity first. That advice is wrong often enough to be worth replacing. A critical vulnerability in a package that only runs in your test suite is less urgent than a moderate one in the library that parses incoming requests.
A better order:
Is it reachable from untrusted input? Anything in the path from a user request to your code: web framework, parser, template engine, image handler, authentication library. Fix these first regardless of label.
Is it a runtime dependency or a development one? A vulnerability in a build tool matters if your build runs untrusted code, and matters much less otherwise. Check whether the package is in your production dependency list at all.
Does the exploit need conditions you do not have? Many advisories require a specific configuration flag, a particular platform or a feature you never enabled. The advisory text says so. Read it.
Is there a fixed version? If yes, this is a version bump and a test run. Do it now, in its own commit, so it is easy to revert.
Everything else, batched into a scheduled afternoon rather than handled one alert at a time.
GitHub supports auto-triage rules that automatically dismiss low-risk alerts, which is the mechanical version of steps two and three. Setting those up once is better value than reading the same dismissible alert forty times.
The conversation to have about severity scores
A severity label is an assessment of the vulnerability in general, not in your application. The same flaw can be critical for a public API and irrelevant for a command-line tool that reads only local files. If you have ever wondered why your alert list seems disproportionate to your actual risk, this is why. For the mechanics of how these identifiers and scores are assigned in the first place, we wrote what a CVE is.
Why this matters more on an AI-built project
An AI coding agent adds dependencies as a byproduct of completing a task. You ask for file uploads and three packages arrive, chosen by something that optimised for a working result rather than for a small dependency tree. Nobody decided to take on those packages, which means nobody feels responsible for maintaining them.
Two habits make this manageable. Read the lock file diff on every agent commit, which is where new dependencies actually show up, covered in what a lockfile is and why AI agents change it. And treat a new dependency as a decision rather than an implementation detail, which is easier to do when you understand what npm install just did to your project.
The adjacent risk is a package that is not vulnerable but hostile, which is a different problem with different tooling. GitHub's package firewall, in public preview since 20 October 2026, screens npm downloads before they reach a runner or an agent, and we covered what it does and does not cover in the package firewall release. Plugin and extension supply chains have the same shape, as in when your AI coding tool updates a plugin behind you.
Frequently asked questions
Is Dependabot alerts the same as Dependabot security updates?
No. Alerts tell you. Security updates open pull requests that bump the version for you. They are separate settings, and turning on alerts alone leaves you with a list and no automation.
Do alerts cost anything?
No. Alerts are available on public and private repositories at no cost, which makes the decision to enable them easy. The cost is attention, not money.
Why do I get an alert with no fixed version available?
Because the advisory exists and the maintainer has not released a patch. Your options are to pin to a safe configuration, apply a workaround the advisory describes, replace the package, or accept and document the risk. Dismissing the alert with a reason is better than dismissing it silently, because the reason is what you will want in six months.
Can I rely on this as my only dependency security?
No, and the documentation does not claim you can. It covers known, reviewed vulnerabilities in declared dependencies on one branch. That is a genuinely useful slice of the problem and it is a slice.
For the wider risk picture for people building with AI, see our practical guide to AI risks.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
