In October 2019, GitHub turned on Dependabot security updates by default for every public repository with a vulnerable manifest, and within a few years it became the most common way open source maintainers first learn a dependency is unsafe. The pitch is simple: GitHub's advisory database matches your package.json, go.mod, or pom.xml against known CVEs, and Dependabot opens a pull request bumping the affected package to a patched version. No agent to install, no config to write. That simplicity is exactly why so many engineering teams treat it as their entire vulnerability remediation program — and why so many of those same teams are quietly running dozens of stale, unmerged Dependabot PRs six months later. GitHub Advanced Security (GHAS) extends the same ecosystem with dependency review, secret scanning, and CodeQL, but it doesn't solve the underlying problem: opening a PR is not the same as fixing a vulnerability. Here's what Dependabot actually does, where it stops, and what closing that gap requires.
What Does Dependabot Security Updates Actually Do?
Dependabot security updates scan your dependency manifest against the GitHub Advisory Database (which ingests NVD, npm, RubySec, and vendor advisories) and automatically open a pull request when a direct dependency has a known, patched vulnerability. This is distinct from "Dependabot version updates," a separate opt-in feature configured via dependabot.yml that keeps dependencies current regardless of security status — a distinction that trips up a surprising number of teams who assume enabling one enables both. Security updates are on by default for public repos and can be enabled for private ones under repository settings. When GitHub's advisory database records a fix — say, jackson-databind's fix for CVE-2020-36518, or the November 2021 patch for the ansi-regex ReDoS issue — Dependabot compares your lockfile version against the patched range and, if you're affected, opens a PR with the minimum version bump needed to clear the advisory. It does not scan for misconfigurations, secrets, or code-level vulnerabilities; that's GHAS territory.
How Is Dependabot Different From GitHub Advanced Security?
Dependabot is a free scanning-and-patching feature; GHAS is a paid suite that Dependabot feeds into but doesn't fully belong to. GHAS bundles CodeQL static analysis, secret scanning with push protection, and dependency review (a PR-time diff view showing new vulnerabilities introduced by a dependency change) on top of the same advisory data Dependabot uses. Historically GHAS was licensed per active committer, at roughly $30–49/month depending on term, before GitHub folded much of it into Enterprise and Copilot bundles starting in 2024 — a pricing shift that pushed many mid-sized teams to ask whether they needed the full suite or just the dependency piece. The practical difference for most engineering orgs: Dependabot tells you a dependency is vulnerable and proposes a fix; GHAS additionally tells you whether that vulnerable code path is even reachable in a pull request, before it merges, via dependency review. Neither product tracks whether the PR actually got merged, tested against your runtime environment, or verified as non-breaking — that operational layer sits entirely outside GitHub's product surface.
Why Do So Many Dependabot Pull Requests Never Get Merged?
Dependabot PRs stall because a version bump is a patch recommendation, not a validated fix, and validating it is left entirely to the receiving team. A major-version bump on a package like express or axios can carry breaking API changes; a minor bump on a transitive dependency can silently break a build three layers away from the manifest that triggered it. Teams report Dependabot backlogs in the dozens to hundreds of open PRs on actively maintained monorepos, particularly in organizations running 20+ services with independent dependency trees. Each PR needs CI to pass, a human to review the changelog, and someone to decide whether the fix is worth the regression risk that week — and when security and platform teams are stretched thin, "worth it" quietly becomes "later." The 2023 Sonatype State of the Software Supply Chain report found the median time-to-update for a vulnerable open source dependency, across ecosystems, still runs into weeks even when a fix is available same-day — the bottleneck isn't detection, it's the human triage step Dependabot never automates.
Can You Rely on Dependabot Alone for Supply Chain Security?
No — Dependabot only covers dependencies with a published advisory in GitHub's database, which misses malicious packages, typosquats, and unpublished zero-days by design. Advisory-based scanning is inherently reactive: it can't catch a compromised package version before a CVE or GHSA ID is filed for it. The event-stream incident in November 2018 — where a maintainer handed off a popular npm package to an attacker who injected a Bitcoin-wallet-draining payload into a nested dependency, flatmap-stream — went undetected by advisory-based tooling for over two months because no advisory existed yet. More recently, the XZ Utils backdoor (CVE-2024-3094, disclosed March 29, 2024) was caught by a Microsoft engineer noticing anomalous SSH login latency, not by dependency scanning, because the malicious code was hidden in build artifacts rather than declared as a flagged version. Dependabot is a strong layer for known-CVE remediation on direct dependencies; it was never designed to catch supply chain compromise, and treating it as a full security program leaves exactly the attack class — malicious package injection — that has driven the largest npm and PyPI incidents of the last five years.
What Happens With Transitive Dependencies and Lockfile Sprawl?
Dependabot's PR-per-advisory model breaks down fastest on transitive dependencies, where a single direct package can pull in hundreds of indirect ones you never explicitly chose. Research from dependency-graph studies has repeatedly found that a typical npm application declares a few dozen direct dependencies but resolves to several hundred when transitive packages are counted — meaning most of the actual attack surface in your lockfile was never a decision your team made. When a vulnerability sits four levels deep in a transitive tree, Dependabot can only bump it if the intermediate maintainers have already released a compatible update; if package B hasn't bumped its pin on vulnerable package C, Dependabot has no PR to offer you at all, and the advisory just sits in your Dependabot alerts tab, unresolved, sometimes for months. This is also where monorepos suffer most: a vulnerability affecting a shared transitive dependency can spawn near-identical Dependabot PRs across 15 or 20 services simultaneously, each needing separate review, with no cross-repo view of which ones actually share the exposure or which fix should be prioritized first.
How Safeguard Helps
Safeguard treats Dependabot's output as a signal, not a finish line. Rather than adding another alert feed, Safeguard ingests Dependabot and GHAS advisory data alongside SBOM and build provenance information to answer the question neither tool answers on its own: is this vulnerable dependency actually reachable and exploitable in your running application, and is the proposed PR safe to merge? For teams sitting on a backlog of open Dependabot PRs, Safeguard correlates each one against actual code paths and runtime call graphs, ranking them by real exploitability instead of CVSS score alone, so a team triaging 80 open PRs can see which 6 matter this sprint and which 74 can wait. For the malicious-package blind spot Dependabot can't cover, Safeguard runs continuous behavioral analysis on new and updated packages — flagging install-time script anomalies, unexpected network calls, and typosquat patterns before an advisory exists, closing the exact gap that let incidents like event-stream and the XZ backdoor go unnoticed for weeks. And for transitive dependency sprawl, Safeguard builds a full dependency graph per repository and across your organization, so a shared vulnerable transitive package generates one prioritized remediation task instead of twenty duplicate PRs scattered across unrelated teams. The result isn't a replacement for Dependabot or GHAS — it's the validation, prioritization, and detection layer that turns their alerts into dependency updates your team can actually trust and merge with confidence.