GitHub has expanded Dependabot’s malicious package alerts from the npm ecosystem to eight ecosystems by connecting the GitHub Advisory Database to data from the OpenSSF malicious packages repository. The new coverage includes npm, PyPI, Maven, RubyGems, NuGet, Go, crates.io, and PHP Composer, enabling the detection of malicious dependencies in projects that use languages and tools beyond JavaScript.
Earlier this year, Dependabot began detecting malware within npm dependencies. The new expansion relies on importing OpenSSF records in OSV format rather than building separate detection systems for each ecosystem. According to the post, the OpenSSF repository contains more than 15,000 reports since its launch in 2023, and continues to grow through community reports and automated detection sources, including typosquatting packages, dependency-confusion packages, account takeovers, and malicious prebuilt binaries.
A Unified Malicious Package Data Importer
GitHub’s supply chain security engineering team developed a single importer that follows the pattern of importers used with public advisory repositories. The importer reads files changed since its last run, then validates required fields, types, and formatting against the OSV schema before adding any record to the database. Records that fail validation are rejected and logged for review rather than being automatically modified and passed through.
After passing validation, records are converted into feed entries that include the source, identifier, and CVE identifier when available, while preserving the complete original record as a reference copy. The importer also handles data differences between sources, such as OpenSSF using the name PyPI while GitHub’s database uses pip, representing affected versions as separate values rather than ranges, the absence of a usable version in some reports, and the withdrawal of reports later shown to be incorrect.
Preventing Duplicates and Protecting the Publishing Pipeline
An additional problem arises because GitHub itself contributes data to the OpenSSF repository, while GitHub’s npm malware alerts flow into the repository. To prevent reimporting the same data, the importer relies on the record’s source data in OSV and excludes any entry carrying the ghsa-malware label, because it originally came from GitHub. The post notes that more than half of the new npm reports reaching the repository each month originated from GitHub alerts, so they are excluded as reimport loops.
Malware alerts are published automatically without human review of every report before publication, because delaying an alert by days could give an attacker additional time when a package is stealing credentials. This differs from vulnerability alerts, which typically require human verification of package matching, version ranges, and issue severity.
Three Layers for Handling Incorrect Data
- Batch limits: Each run sets a configurable cap on the number of alerts that can be created. If the data exceeds the cap, the entire run stops and nothing is published, while the exact number of alerts is reported.
- Source tracking: Each alert is linked to the specific commit in the malicious-packages repository, enabling the report’s source to be identified during incidents.
- Rollback: Each batch can be defined and rolled back as a single unit if contaminated data slips through, instead of manually removing alerts from the database.
Activation for Users
Malicious dependency alerts in Dependabot are now optionally available and can be enabled from the security settings for a repository, organization, or enterprise. After activation, Dependabot matches dependencies against malware alerts in the GitHub Advisory Database, including a subsequent matching process with alerts that already exist.