OSV consists of:
We created OSV to address many of the shortcomings of dealing with vulnerabilities in open source software using existing solutions.
See our blog posts for more details:
The OSV schema and OSV.dev can be used by:
We found that there was no existing standard format which:
A unified format means that vulnerability databases, open source users, and security researchers can easily share tooling and consume vulnerabilities across all of open source. This means a more complete view of vulnerabilities in open source for everyone, as well as faster detection and remediation times resulting from easier automation.
The benefits of the OSV schema have led to adoption by several vulnerability databases, including GitHub Security Advisories, PyPA, RustSec, and many more. The full list of databases can be found here.
OSV.dev provides an easy-to-use API for querying against the aggregated database of vulnerabilities.
Command line tooling is also available for vulnerability scanning of SBOMs, language manifests, and container images.
There are numerous third-party integrations with the API, and we have stopped maintaining an exhaustive list. You can try this GitHub search as a starting point.
By making your vulnerability database available in the OSV format, open source users will have a consistent way to consume vulnerabilities across all open source ecosystems.
Vulnerability databases can also benefit from easier interchange and vulnerability sharing from other databases that use the OSV format.
OSV is completely open source!
If you have any questions, please feel free to create an issue!
Data quality is very important to us. Please remember that OSV.dev is an aggregator of OSV records from a variety of sources and the most appropriate place to correct the data is at the source.
We prefer to avoid needing to act as a broker between downstream consumers of the data and upstream sources, as this adds limited value, and only adds delays.
Where available, a human-friendly link to the authoritative record source is
available as the Source
field on the individual vulnerability page. You should
follow the source-specific process for updating the data.
For sources that are a Git repository, the Import Source
field points to the
authoritative source of the data, and you may be able to create a pull/merge
request or file an issue against the repository.
If you are not able to get satisfaction after dealing directly with the source of the data, please file an issue tagged with data quality
.
Yes!
The database in available in a GCS bucket maintained by OSV: gs://osv-vulnerabilities (also publicly browseable via the Google Cloud Console with a login)
More information about how to download the database is available here.
Yes!
If you work on a project (like a Linux distribution) and would like to contribute security advisories, please see our data contribution guide on GitHub.
Both version and commit enumeration populate the affected.versions[]
field, which assists with precise version matching.
In some cases, there may be no applicable versions, so the affected.versions[]
array is empty. This field, when empty, is omitted in the API output, and
present (but empty) in the data exports.
Records that have the withdrawn
field set will be excluded from:
The entry remains in the database, and is:
/vulns/<ID>
GET APIhttps://osv.dev/vulnerability/<ID>
page (and clearly visibly marked as “withdrawn”)withdrawn
field)When a record is deleted from an upstream source, OSV.dev currently handles them differently, depending on where they’re imported from:
withdrawn
. There is additionally a safety threshold in the case of feed availability issues: if more than 10% of records are about to be marked as withdrawn
, OSV.dev aborts and does not proceed.No. Currently there is not a limit on the API.
OSV.dev strives to provide reliable vulnerability information to our users. To support that goal, the following service level objectives are targeted: