GitHub Malware Advisories Now Cover Eight Package Ecosystems

Last updated: August 6, 2026

GitHub has expanded its malware advisory coverage from npm to all eight major package ecosystems. The GitHub Advisory Database now ingests reports from OpenSSF's malicious-packages repository, which means Dependabot malware alerts now cover npm, PyPI, Maven, RubyGems, NuGet, Go, crates.io, and PHP Composer. This is the first time an auto-published advisory can trigger a Dependabot alert.

What Changed#

Until now, GitHub's malware detection was npm-only. It ran through a separate, internal path built around GitHub's own detection of malicious npm packages, and Dependabot started flagging that malware in March 2026. Expanding that detection to eight ecosystems by building eight detection systems would have taken years, so the team built one importer instead.

The importer follows the same pattern as GitHub's existing repo-based advisory importers (RubySec for gems, RustSec for crates, PyPA for Python): walk the source repository's file tree, pick up files changed since the last run, and process each one. The new source is OpenSSF's malicious-packages repo, which launched in 2023 with over 15,000 reports in OSV format and has grown every day since, fed by community submissions and automated detection across the industry: typosquats, dependency-confusion packages, account takeovers, and malicious prebuilt binaries.

Before anything touches the database, each record is validated against the OSV schema. A record that fails validation is rejected and logged, not quietly patched up, because a "mostly valid" malware advisory is exactly the kind of thing that bites six months later.

The Hard Part Is the Data, Not the Format#

The interesting engineering is in normalization. Upstream ecosystem strings do not always match GitHub's (the repo says PyPI, the database says pip). OSV records list affected versions as discrete values where the Advisory Database thinks 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 an osv/withdrawn folder for advisories that turned out to be wrong, so the importer has to cope with a package being flagged on Monday and disavowed on Wednesday.

Then there is the round-trip problem. GitHub is itself a contributor to the OpenSSF repo: its own npm malware advisories flow upstream. A naive import would re-import GitHub's own data in a loop. The fix rides on OSV origin metadata: anything tagged ghsa-malware began with GitHub and is dropped before a feed entry is created. In live validation, more than half of the new npm reports flowing into the repo each month traced back to GitHub's own advisories and were skipped, so the importer picks up what GitHub genuinely did not know about.

Auto-Publish With Three Safety Layers#

One question dominated the security review: what happens if the upstream data goes bad? Malware advisories auto-publish with no human reading each one, and that is deliberate: when a package is stealing credentials right now, a review queue measured in days is a gift to the attacker. The report is close to binary (this package is hostile), and hours matter more than nuance.

Against that risk, the pipeline has three layers of protection:

• Batch caps. Each import run has a configurable ceiling on how many advisories it may create. Blow past it and the run does not trim to fit, it halts completely, publishes nothing, and pages the team with the exact count.
• Provenance. Every imported advisory traces back to the exact upstream commit in the malicious-packages repo, so during an incident the team can tell in minutes whether a bad advisory came from a legitimate but wrong upstream report or something more deliberate.
• Rollback. If a poisoned batch lands anyway, every batch is identifiable and revertible as a unit. One rollback, clean slate.

What This Means for You#

Malware alerts are opt-in. Enable them in your repository, organization, or enterprise security settings, and Dependabot matches your dependencies against malware advisories in the Advisory Database, including a backfill against existing advisories starting the moment you turn it on. For context on scale: Dependabot watches over 30 million repositories across 34 package ecosystems.

My take: the opt-in requirement is the right call, and the batch-cap design is the most underrated detail in the announcement. Supply-chain alerting systems that auto-publish need a circuit breaker, because a compromised upstream feed is exactly the scenario where the alert channel becomes part of the attack surface. Teams that enable this for PyPI and crates.io specifically close a real gap: Python and Rust supply chains have been the target of repeated malicious-package campaigns this year, and most developers only had npm covered.

How This Fits With the Rest of the Ecosystem#

This lands in a busy stretch for supply-chain security. The Mastra npm attack and the Miasma campaign showed how quickly malicious packages reach production, and the TanStack compromise demonstrated that agent workflows inherit every weak trust boundary in CI. GitHub's move to standardize on OpenSSF's shared data is a step toward the industry consolidating on one malicious-package dataset instead of every registry maintaining its own. The flip side of that consolidation is now explicit: anyone who ingests that feed needs the same provenance, caps, and rollback discipline GitHub just shipped. For agent-heavy teams, the alerting surface is also relevant to how agents handle dependency updates: agent workflows that touch CI and prompt-injection in open source are exactly where a compromised dependency does the most damage.

FAQ#

Which package ecosystems do GitHub malware advisories cover?#

Eight: npm, PyPI, Maven, RubyGems, NuGet, Go, crates.io, and PHP Composer. Before this expansion, GitHub's malware detection was npm-only.

Where does GitHub get the new malware advisory data?#

The GitHub Advisory Database now imports reports from OpenSSF's malicious-packages repository, which publishes in OSV format. Each record is validated against the OSV schema, and records tagged ghsa-malware are dropped because they originated with GitHub itself.

How do I turn on Dependabot malware alerts?#

Malware alerts are opt-in. Enable them in your repository, organization, or enterprise security settings, and Dependabot matches your dependencies against malware advisories, including a backfill against existing advisories from the moment you turn it on.

Are imported malware advisories reviewed by a human?#

No, they auto-publish so alerts arrive in hours rather than days. The pipeline relies on three safety layers instead: batch caps that halt a run entirely, provenance back to the exact upstream commit, and rollback of any batch as a unit.

Continue Reading#

• Mastra npm Supply Chain Attack: What Happened and How to Protect Your AI Stack
• Miasma Supply Chain Attack: What AI Developers Need to Know
• TanStack's npm Compromise Is the CI Lesson Agent Teams Needed
• Reference Same-Repository Actions With Self Repository Syntax
• Why Prompt Injection Is the Supply Chain Problem of AI Development
• GitLost: How Researchers Tricked GitHub's AI Agent Into Leaking Private Repos
• arrayref 0.3.10 Ran a Remote Payload at Build Time - the compromised arrayref 0.3.10 release whose typosquat build script fetched a remote binary, and why agents running cargo update walk into it
• LiteLLM 1.107.0 Compromised: Check, Clean and Rotate - the October 2026 PyPI compromise of an LLM gateway and the rotation order

Sources#

• How we took malware advisories beyond npm - GitHub Blog
• OpenSSF malicious-packages repository
• Dependabot now detects malware in npm dependencies - GitHub Changelog
• Dependabot malware alerts - GitHub Docs