DevSecOps

GitHub Dependabot and the State of Automated Dependency Security

Dependabot has become the default for dependency updates, but its limitations highlight why automated scanning alone isn't enough for supply chain security.

James
Engineering Lead
5 min read

By mid-2023, GitHub Dependabot had become the de facto standard for automated dependency updates. Enabled by default on public repositories and widely adopted in enterprises, Dependabot generates millions of pull requests per month, nudging developers to update vulnerable dependencies. But as supply chain attacks grow more sophisticated, it's worth asking: is Dependabot enough?

What Dependabot Does Well

Dependabot provides three core capabilities:

Dependabot alerts notify repository owners when a known vulnerability (CVE) is found in their dependency graph. These alerts pull from the GitHub Advisory Database, which aggregates data from the National Vulnerability Database, security advisories from package registries, and community contributions.

Dependabot security updates automatically create pull requests to update vulnerable dependencies to the minimum patched version. These PRs include changelogs, release notes, and compatibility scores to help developers assess the update.

Dependabot version updates go beyond security patches to keep dependencies current with the latest versions, reducing the accumulation of technical debt that makes security updates harder over time.

For most open-source projects, this is a massive improvement over the status quo ante. Before tools like Dependabot (and its predecessor, Greenkeeper), dependency updates were a manual process that most teams simply didn't do regularly. Vulnerabilities would sit unpatched for months or years.

Where Dependabot Falls Short

Despite its strengths, Dependabot has significant limitations that security-conscious organizations need to understand:

1. It Only Catches Known Vulnerabilities

Dependabot relies on the GitHub Advisory Database, which in turn relies on CVE assignments and vendor advisories. If a vulnerability hasn't been assigned a CVE or published in an advisory, Dependabot won't catch it.

This matters because:

  • Many vulnerabilities are fixed silently in patch releases without CVE assignments
  • Zero-day vulnerabilities by definition have no advisory when exploitation begins
  • Malicious packages (typosquatting, dependency confusion) often don't have CVEs

2. It Doesn't Assess Reachability

Dependabot tells you that a vulnerable dependency is in your tree, but not whether the vulnerable code path is actually reachable from your application. A dependency with a critical vulnerability in a function you never call might be flagged with the same priority as one that's directly exposed.

This leads to alert fatigue. Development teams receiving dozens of Dependabot PRs per week start ignoring them or auto-merging without review—both of which are worse than not having the tool.

3. Transitive Dependencies Are Harder

When a vulnerability exists in a transitive (indirect) dependency, Dependabot's behavior varies by ecosystem. In some cases, it can update a direct dependency to pull in a fixed transitive version. In other cases, it can only alert you and leave the resolution to manual intervention.

For deeply nested transitive dependencies, the resolution path might require updates across multiple levels of the dependency tree, which Dependabot can't orchestrate.

4. It Doesn't Cover All Ecosystems Equally

Dependabot's coverage varies significantly across package ecosystems. npm, pip, Maven, and Go modules have strong support. But niche ecosystems, system packages, and container base images receive less coverage.

5. It Doesn't Detect Malicious Packages

Dependabot is a vulnerability scanner, not a malware scanner. It won't detect a dependency that is intentionally malicious—such as a typosquatting package, a compromised maintainer account pushing malicious updates, or a dependency confusion attack.

The Dependabot Fatigue Problem

In 2023, "Dependabot fatigue" became a widely discussed phenomenon. Engineering teams reported being overwhelmed by the volume of automated PRs:

  • Large monorepos might receive hundreds of Dependabot PRs per week
  • Many updates are for low-severity issues in deeply transitive dependencies
  • Breaking changes in updates create CI failures that require manual investigation
  • Teams start ignoring or batch-closing PRs, defeating the purpose

Some organizations addressed this by configuring Dependabot to only open security updates (not version updates), grouping updates, or setting update schedules to weekly or monthly rather than daily. Others switched to alternative tools like Renovate, which offers more granular configuration.

Beyond Dependabot: A Layered Approach

Effective dependency security requires layering multiple approaches:

SBOM generation and analysis. Know exactly what's in your software, including transitive dependencies, build tools, and runtime components. Dependabot covers your declared dependencies, but an SBOM covers everything.

Malware scanning. Tools that analyze package contents for malicious behavior—obfuscated code, network calls to suspicious domains, file system access—catch threats that vulnerability databases miss.

License compliance. Dependencies can introduce legal risk alongside security risk. Tracking licenses across your dependency tree is a related but distinct concern.

Reachability analysis. Understanding whether vulnerable code paths are actually reachable from your application lets you prioritize the vulnerabilities that matter.

Dependency review before merge. GitHub's dependency review action checks PRs for new vulnerabilities before they're merged, preventing the introduction of known-vulnerable dependencies.

Private registry controls. Using a private package registry (Artifactory, Nexus, Verdaccio) as a proxy to public registries lets you control what packages are available to your developers and scan packages before they enter your environment.

The Role of Dependabot in 2023

Dependabot remains an essential tool. It raises the floor of dependency security for millions of projects. For individual developers and small teams, it's often sufficient.

But for organizations with serious security requirements, Dependabot is the starting point, not the destination. The supply chain threat landscape has evolved beyond what a CVE-based scanner can address alone.

How Safeguard.sh Helps

Safeguard.sh complements Dependabot by providing the deeper analysis that automated PR generators can't. Our platform offers reachability analysis to prioritize vulnerabilities that actually affect your application, malware detection for malicious packages, comprehensive SBOM generation that covers your entire software supply chain, and continuous monitoring that goes beyond CVE databases to detect supply chain anomalies. Where Dependabot tells you a dependency is vulnerable, Safeguard.sh tells you whether it matters and what to do about it.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.