What is OSV (osv.dev)?

OSV (Open Source Vulnerabilities) is a distributed vulnerability database for open source software, hosted at osv.dev. It aggregates vulnerability information across many open source ecosystems and package managers, and publishes every advisory in the OpenSSF OSV format — a human- and machine-readable schema that maps vulnerabilities precisely to package versions or commit hashes. It is useful if you maintain an open source project, consume dependencies, or build security tooling and need a single place to look up whether a specific package version is affected by a known vulnerability.

What OSV provides

• A searchable vulnerability database covering open source ecosystems and distributions.
• A consistent data format (the OSV schema) so the same advisory can be read by people and parsed by tools.
• An API for programmatic access, plus a Vulnerability Scanner and pointers to remediation tools and GitHub workflows.
• Per-ecosystem browsing, so you can see advisories scoped to the ecosystem you actually use.

Coverage by ecosystem

OSV lists advisories per ecosystem. The counts below are taken from the site's ecosystem listing and reflect what was shown at the time of writing, so treat them as indicative rather than fixed:

The listing also includes AlmaLinux, Alpaquita, Alpine, Android, Azure Linux, BellSoft Hardened Containers, Bitnami, CleanStart, Echo, Hackage, Hex, Julia, Mageia, openEuler, openSUSE, OSS-Fuzz, Rocky Linux, Root, SwiftURL, and TuxCare, among others. Coverage is broad but not uniform — some ecosystems have far more advisories than others, and a low count can reflect either fewer known vulnerabilities or less complete sourcing.

The OSV schema

Every advisory in the database uses the OpenSSF OSV format, developed with open source communities. The schema is designed so a vulnerability maps precisely to open source package versions or commit hashes, rather than to vague product names. A record includes fields such as:

• schema_version — the schema revision in use
• id — the OSV identifier
• modified and published — timestamps
• aliases — cross-references, for example a CVE ID
• summary — a short description

Because the format is both human- and machine-readable, the same record can be displayed on the site and consumed by scanners or CI checks without a translation layer.

Who it is for

• Open source maintainers who want to check whether a dependency or their own project appears in the database.
• Dependency consumers who need to confirm whether a specific package version is affected.
• Security tool developers who want a structured feed rather than scraping prose advisories.
• Teams wiring vulnerability checks into CI, using the API, the scanner, or the GitHub workflows referenced on the site.

How to start using it

1. Search the database. Use the search on osv.dev with a package name, ecosystem, or vulnerability ID. Expected result: matching advisories with their IDs, aliases, and affected version ranges.
2. Browse by ecosystem. If you are not searching for a specific package, open the ecosystem list to see advisories scoped to your platform. Expected result: a filtered view of that ecosystem's vulnerabilities.
3. Use the API when you need this programmatically — for example, to check a list of dependencies in a build pipeline. Expected result: structured OSV records you can parse.
4. Try the Vulnerability Scanner if you want to scan a project rather than query individual packages.
5. Check remediation tools and GitHub workflows if you want fixes or automated checks integrated into your repository.

Practical notes and limits

• Counts change. The ecosystem numbers are a snapshot; advisories are added and updated over time.
• Coverage varies by ecosystem. A package not appearing in OSV does not by itself prove it is unaffected — it may simply not be covered by the data sources feeding that ecosystem.
• Aliases matter. A record may carry a CVE alias alongside its OSV ID, so search by either when cross-referencing other databases.
• The schema is the point. If you are building tooling, rely on the structured fields (affected versions, commit hashes, aliases) rather than the summary text, which is descriptive and not meant for matching.