Which ecosystems and package sources does OSV cover?

Updated

OSV (osv.dev) aggregates open source vulnerability data across two broad categories: language and package-manager ecosystems (npm, PyPI, Maven, Go, crates.io, NuGet, RubyGems, Packagist, Hex, Hackage, and others) and Linux distribution or OS-level sources (Debian, Ubuntu, Alpine, Red Hat, SUSE, openSUSE, Rocky Linux, AlmaLinux, and more). Each ecosystem has its own vulnerability count on the site, and the exact set of sources can change as data providers are added or updated.

Language and package-manager ecosystems

These cover vulnerabilities tied to packages published through language-specific registries and build tools:

Ecosystem Approx. advisories listed
npm 228,869
PyPI 25,190
Maven 7,044
Go 9,245
crates.io 2,739
NuGet 1,869
RubyGems 5,326
Packagist 7,098
Hex 364
Hackage 33
Julia 1,713
SwiftURL 60
GitHub Actions 55

The counts above are the figures shown on the OSV site at the time of writing and are not fixed — they grow as new advisories are published.

Linux distributions and OS-level sources

OSV also pulls from distribution security trackers and OS vendors, which is useful when you need to check a system package rather than a language library:

Source Approx. advisories listed
Chainguard 1,030,811
Wolfi 289,821
MinimOS 145,008
Debian 68,551
Ubuntu 65,628
Linux 29,974
Red Hat 23,387
SUSE 23,350
Root 19,581
Azure Linux 17,651
Alpaquita 16,087
openSUSE 14,480
TuxCare 9,606
openEuler 8,800
Mageia 6,232
AlmaLinux 5,931
Alpine 4,608
Rocky Linux 4,305
CleanStart 3,846
Android 3,677
BellSoft Hardened Containers 754
OSS-Fuzz 4,013

Other sources worth noting

  • GIT (108,258 entries) — commit-level advisories, which matter when a fix exists in a repository but hasn't shipped in a tagged release.
  • OSS-Fuzz — findings from Google's fuzzing infrastructure, often earlier than a formal CVE.
  • Android — relevant if you track AOSP components.

How the data is structured

All advisories use the OpenSSF OSV schema, a machine- and human-readable format that maps vulnerabilities to precise package versions or commit hashes. A typical record includes fields like schema_version, id, modified, published, aliases (e.g., a CVE ID), and summary. This is what lets OSV match a vulnerability to the exact version range affected rather than a vague "before version X" statement.

Practical implications

  • If you use a language registry, check whether your ecosystem is listed before assuming OSV covers it — most major ones are, but smaller or newer registries may not be.
  • If you run Linux, distribution sources like Debian, Ubuntu, Red Hat, and Alpine are covered, so you can query OSV for system packages too.
  • Coverage is not static. Counts and the list of ecosystems change as OSV adds or updates data sources, so re-check the site if you're relying on a specific source being present.

To browse a specific ecosystem, go to osv.dev and select it from the Ecosystems list, or query the API directly for programmatic lookups.