GitHub Dependabot malware alerts now cover eight ecosystems

GitHub Dependabot malware alerts now cover eight ecosystems GitHub has flagged npm malware since March 2026. Anyone pulling in a bad PyPI, Maven, RubyGems, NuGet, Go, crates.io, or PHP Composer package has had no such warning, because GitHub’s malware detection only ever watched one ecosystem. That changed this month. GitHub’s Advisory Database now ingests malware reports from OpenSSF’s malicious-packages repository, a public feed in OSV format that launched in 2023 with more than 15,000 reports and has grown daily since, covering typosquats, dependency-confusion packages, account takeovers, and malicious prebuilt binaries. Dependabot malware alerts, which had run on npm data alone, now draw on all eight ecosystems the moment a user turns malware alerts on. Dependabot itself already runs across more than 30 million repositories and 34-plus package ecosystems overall, which gives a sense of the scale the malware pipeline now has to operate at. One importer instead of eight Building eight separate detection systems would have taken years. Instead, the team built one importer that reads OpenSSF’s feed the way GitHub’s existing importers already read RubySec and RustSec advisories, and maps the records in. “Normalizing sounds boring until you meet the data. Upstream ecosystem strings don’t always match ours (the repo says PyPI , our database says pip ). OSV records list affected versions as discrete values where we think in ranges, and some records name no usable version at all. The details field is frequently empty, and when several sources report the same package, their write-ups get appended into one blob. Reports also get retracted: the repo keeps a whole osv/withdrawn folder for advisories that turned out to be wrong, so the importer must cope with a package being flagged on Monday and disavowed on Wednesday,” Ankit Kumar Honey, Senior Engineering Manager at GitHub, wrote. There’s a subtler wrinkle: GitHub’s npm malware findings already flow into OpenSSF’s repository. Importing that feed without filtering would mean re-importing GitHub’s own advisories in a loop. The fix relies on origin metadata OSV records carry: any entry tagged “ghsa-malware” started at GitHub and gets dropped before it becomes a new feed entry. Once GitHub checked this against live data, more than half of the new npm reports arriving each month turned out to be exactly this kind of round-trip. The review step got skipped on purpose Madison Ficorilli, a colleague at GitHub, has written about what “reviewed” means for vulnerability advisories: a human checks package mappings, version ranges, and severity before anything ships. Malware advisories skip that step and publish automatically, on purpose, because a credential-stealing package sitting in a review queue for days is a win for whoever planted it. What’s new is that these unreviewed advisories can now trigger Dependabot alerts directly, something that was never true before this expansion. What happens if the upstream feed goes bad That arrangement only holds if the upstream feed stays clean, so the pipeline assumes it eventually won’t. Three safeguards cover that case. A batch cap limits how many advisories a single import run can create; exceed it and the run stops entirely, publishes nothing, and pages the team, because a run wanting five times the usual volume looks less like a busy day and more like a compromised source. Every imported advisory carries provenance back to the exact upstream commit, so a bad advisory can be traced to its origin in minutes. And every batch can be reverted as a single unit, without anyone hand-picking bad records out of the database after the fact. Turning it on “Malware alerts are opt-in: enable them in your repository, organization, or enterprise security settings. Dependabot will match your dependencies against malware advisories in the Advisory Database, including a backfill against existing advisories, starting the moment you turn it on,” Honey explained.