In September 2025, a phishing email disguised as an "npm support" notice tricked a maintainer into handing over credentials for packages including debug and chalk — two libraries downloaded a combined two billion-plus times a week. Attackers pushed versions laced with a crypto-clipping payload, and the malicious code sat live on the npm registry for hours before it was pulled. Dependabot, the dependency alerting tool bundled into GitHub Advanced Security (GHAS), didn't stop it. It couldn't have: Dependabot alerts fire when a package matches a known entry in the GitHub Advisory Database, and there was no advisory yet. That gap — between a malicious package going live and someone cataloging it — is the recurring story behind nearly every major open source supply chain attack of the last decade. Here's what Dependabot actually does, where GitHub Advanced Security's malware coverage stops, and what closes the gap.
Does Dependabot Detect Malware?
No — Dependabot is a vulnerability-matching tool, not a malware scanner. It compares the packages in your manifest files (package.json, requirements.txt, go.mod, and similar) against the GitHub Advisory Database (GHSA) and the National Vulnerability Database, then opens an alert or a pull request when it finds a match. That workflow was built for CVEs: a known SQL injection bug in a specific version range of a specific library. It works well for that job — GitHub's own advisory database spans well over 300,000 entries across ecosystems. But a freshly published malicious package has no CVE, no CVSS score, and often no advisory at all for the first hours or days of its life, because advisories are written after someone notices and reports the package. Dependabot has nothing to match against until that happens, so it stays silent while the malicious version sits in node_modules on every machine that ran npm install in that window.
How Does GitHub Advanced Security Handle Malicious Packages?
It relies on a manually curated malware review track feeding into the same advisory pipeline Dependabot already reads from. GitHub introduced a distinct "malware" classification in the GitHub Advisory Database so reports of intentionally malicious packages — not just accidental vulnerabilities — could be tracked and, in the npm ecosystem, used to pull packages from the registry. GHAS bundles this together with code scanning (CodeQL) and secret scanning as its supply chain story. The catch is the review step: someone — a researcher, a maintainer, an automated registry scan — has to flag the package, and a human has to confirm and publish the entry before Dependabot users ever see an alert. For a short-lived campaign, that review cycle can easily outlast the attack itself. The xz-utils backdoor (CVE-2024-3094) shows how long even sophisticated, patient cases can take: malicious code was quietly built into release tarballs for versions 5.6.0 and 5.6.1 after roughly two years of social-engineered maintainer trust, and it was only caught in March 2024 when a Microsoft engineer, Andres Freund, noticed unusual SSH login latency and traced it back.
What Real Attacks Got Past Advisory-Based Detection?
Several of the largest npm and PyPI incidents on record ran their full course before an advisory existed to catch them. In November 2018, the event-stream package — pulled into thousands of projects — was handed to a new "maintainer" who added a dependency, flatmap-stream, that targeted a specific Bitcoin wallet app, and it went unnoticed for roughly two and a half months. In October 2021, ua-parser-js, used in millions of weekly installs, had its npm account hijacked and three malicious versions published carrying a cryptominer and password stealer; they were pulled within hours of public reports, but only after countless builds had already installed them. In September 2025, the shai-hulud worm spread through compromised npm packages by harvesting CI/CD tokens with TruffleHog and republishing itself into every package a stolen token could reach, ultimately touching several hundred packages, including ones maintained by security vendors. In every case, the packages were live and installable on the public registry before any advisory — and therefore before any Dependabot alert — existed.
Why Does an Advisory-Database Model Create a Blind Spot?
Because it is inherently reactive: it can only alert on what's already been reported, reviewed, and published, so every attack gets a head start measured in hours to months. Even a same-day advisory turnaround leaves a window where every npm install, pip install, or go get pulls the compromised version with zero warning. That window is exactly where attackers now operate. The shift over 2024 and 2025 has been away from patient, multi-year backdoors like xz-utils and toward smash-and-grab campaigns — credential-stealing install scripts, crypto-clippers, CI token exfiltration — designed to extract value in the hours before anyone notices, let alone writes an advisory. A detection model built around cataloging incidents after the fact is structurally mismatched to attacks designed to be short-lived and disposable. With npm alone publishing well over a million new package versions a month, and PyPI, RubyGems, and crates.io adding their own steady volume, the sheer surface area means a purely reactive queue of human-reviewed advisories will always be playing catch-up with automated publishing.
Can Dependabot Catch Typosquatting or Dependency Confusion?
Generally not, because those attacks don't depend on vulnerable code — they depend on a name. Typosquatting (publishing reqeusts to catch a typo of requests) and dependency confusion (publishing a public package that matches the name of a company's private internal package, so a misconfigured build pulls the attacker's version instead) both work by getting malicious code installed under a plausible-looking name, not by shipping a flawed but legitimate library. There's no CVE for "this package name looks like another package," and unless someone has specifically reported that exact typosquat to the advisory database, Dependabot has nothing to alert on — the package isn't vulnerable, it's malicious by design. This category keeps growing; researchers publish new batches of typosquatted PyPI and npm packages on a near-monthly cadence, and most are caught by registry-operator takedowns rather than by any downstream dependency scanner noticing during a build.
How Safeguard Helps
Safeguard is built for exactly the gap that advisory-database tools like Dependabot leave open: the window between when a malicious package is published and when someone gets around to reporting it. Instead of matching package names and versions against a catalog of known-bad entries, Safeguard analyzes package contents directly — install scripts, obfuscated code, unexpected network calls, and behavior that deviates from a package's prior release history — at the point a new version is published or pulled into a build, not weeks later when an advisory finally lands. That means a compromised maintainer account pushing a credential-stealing postinstall script, a dependency-confusion package matching your internal namespace, or a fresh typosquat with no CVE and no GHSA entry can all be flagged before they reach a developer's machine or a CI pipeline, rather than after the incident report is written.
Safeguard also re-evaluates dependencies you've already shipped, not just new pulls: a package that looked clean six months ago — the way xz-utils did for years — can be reassessed the moment new behavioral or reputational signals emerge, and every build or deployment that already includes it gets flagged retroactively. For teams already running Dependabot or GitHub Advanced Security, Safeguard isn't a replacement for CVE tracking — it's the layer that catches what a purely reactive, advisory-driven model is structurally unable to see until it's too late.