From npm-only to eight ecosystems
GitHub’s Advisory Database has long imported vulnerability data from external sources such as RubySec, RustSec and PyPA. Malware was different. Until recently it arrived through a separate, internal path limited to npm packages that GitHub itself detected.
That changed when the supply-chain engineering team behind Dependabot decided to stop building eight separate detection systems. Instead they built one importer that consumes the OpenSSF malicious-packages repository.
OpenSSF launched the repo in 2023. It now holds more than 15,000 reports in OSV format, updated daily by community submissions and automated detectors covering typosquats, dependency-confusion packages, account takeovers and malicious binaries. The schema already supports every major package ecosystem.
How the importer works
The new OpenSSF importer follows the same pattern GitHub already uses for its other repo-based importers. It walks the source repository’s file tree, picks up files changed since the last run, and processes each OSV record.
Every record is validated against the schema for required fields, types and format. A record that fails validation is rejected and logged; nothing is quietly patched and waved through. Valid records are normalized into feed entries that capture the source, an identifier, any CVE ID, a complete upstream snapshot, and the mapped subset the publishing pipeline needs.
Normalization is not trivial. Upstream ecosystem strings sometimes differ from GitHub’s internal names. OSV records list discrete versions where GitHub thinks in ranges. Some records name no usable version at all. The details field is often empty, and when several sources report the same package their write-ups are concatenated. Reports also get retracted; the importer must handle a package being flagged on Monday and withdrawn on Wednesday.
Deduplication required special care. GitHub itself contributes npm malware advisories to the OpenSSF repo. A naïve import would re-ingest GitHub’s own data in a loop. The fix uses OSV origin metadata: any entry tagged as originating from GitHub is dropped before a feed entry is created. In live validation more than half of the new npm reports each month were GitHub’s own and were correctly skipped.
Auto-publish with deliberate safeguards
Malware advisories publish automatically. No human reviews each one before it goes live. The design is intentional: when a package is actively stealing credentials, a review queue measured in days helps the attacker. This is the first time an auto-published advisory can also generate a Dependabot alert.
The team assumes the upstream feed could one day carry bad data: a false report against a widely used package, a wrong package name, or a batch from a compromised source. Three layers of protection sit in front of that possibility.
First, each import run has a configurable ceiling on the number of advisories it may create. Exceed the ceiling and the entire run halts, publishes nothing, and pages the team with the exact count. A sudden five-fold jump is treated as a red flag, not throughput.
Second, every record carries provenance that points back to the exact upstream commit in the malicious-packages repo. During an incident the team can tell within minutes whether a bad advisory came from a legitimate (if incorrect) report or something more deliberate.
Third, every batch is identifiable and can be rolled back as a unit. One command restores a clean slate instead of hand-picking individual advisories out of the database.
What developers need to do
Malware alerts are opt-in. Enable them in repository, organization or enterprise security settings. Once turned on, Dependabot matches dependencies against the expanded Advisory Database, including a backfill of existing advisories.
The result is that the same malware protection previously limited to npm now covers the eight major ecosystems most teams actually use. The pipeline is designed for speed when hours matter and for resilience when the data source is imperfect.