Where Does OSV Get Its Vulnerability Data?

OSV (osv.dev) aggregates vulnerability data from many upstream sources rather than producing its own advisories. The site lists a "Data sources" section and organizes coverage by ecosystem, so each entry you see in the database traces back to a specific upstream provider — a language package registry, a Linux distribution security team, or a fuzzing project. If you need to judge whether OSV is reliable for a given dependency, the practical answer is: check which upstream feeds that ecosystem, then verify the specific advisory against the original source.

How the data is structured

OSV describes itself as "a distributed vulnerability database for Open Source" using "an open, precise, and distributed approach to producing and consuming vulnerability information." Two things follow from that:

• Aggregation, not authorship. OSV collects and normalizes advisories that upstream projects and distributions publish.
• A single schema. All advisories use the OpenSSF OSV format, which the site says was "developed in collaboration with open source communities." The schema is both human- and machine-readable and "precisely maps to open source package versions or commit hashes."

A record follows this shape (abbreviated from the site's example):

{
  "schema_version": "1.7.4",
  "id": "GHSA-c3g4-w6cv-6v7h",
  "modified": "2022-04-01T13:56:42Z",
  "published": "2022-04-01T13:56:42Z",
  "aliases": ["CVE-2022-27651"],
  "summary": "Non-empty defaul..."
}

The aliases field is the key to tracing data: an OSV ID can be linked to a CVE or another identifier, which is how you cross-check an entry against the original advisory.

Where the data comes from, by ecosystem

The homepage groups sources under "Ecosystems," each with a vulnerability count. These are the upstream feeds OSV draws on:

Counts are as shown on the site and change over time. The takeaway is that coverage is broad across language ecosystems and distributions, but each entry's authority comes from the named upstream — OSV is the aggregator, not the originator.

What this means for using OSV as a security reference

• Traceability is built in. Because records carry aliases and follow one schema, you can move from an OSV entry to the CVE or upstream advisory behind it.
• Verify before acting. The site's own framing is aggregation across sources; for a specific dependency, confirm the affected version range and fix in the original advisory, since upstream feeds differ in how quickly and completely they publish.
• Coverage is uneven by design. A registry with a mature security process (npm, PyPI, major distros) will have richer data than a smaller or newer source. The per-ecosystem counts make this visible.
• Machine consumption is the point. The OSV schema and the site's API are intended for automated tooling, so you can query by package and version rather than reading advisories by hand.

If your question is simply "can I trust OSV," the answer is that it is a consolidation layer over sources you can identify and check — useful for broad, cross-ecosystem scanning, with the original advisory as the final authority on impact.