Table of contents
- What is OSV?
- Who is OSV for?
- Why a new format to describe vulnerability?
- Who is using the OSV schema?
- What does OSV.dev do to the records it imports?
- How do I use OSV as an open source user?
- How do I use OSV as a vulnerability database maintainer?
- Is the database available to download?
- What are OSV’s service level objectives (SLOs)?
- How do I contribute to OSV, or ask a question?
- Can I contribute data?
- Is the API rate limited?
OSV consists of:
- The OSV Schema: An easy-to-use data format that maps precisely to open source versioning schemes.
- Reference infrastructure (this site, API, and tooling) that aggregates and indexes vulnerability data from databases that use the OSV schema.
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:
- Launching OSV
- Announcing a unified vulnerability schema for open source
- OSV and the Vulnerability Life Cycle
The OSV schema and OSV.dev can be used by both:
- Open source consumers: By querying OSV.dev’s API and using our tooling to find known vulnerabilities in their dependencies.
- Vulnerability database producers: By making the database available in the OSV format.
We found that there was no existing standard format which:
- Enforces version specification that precisely matches naming and versioning schemes used in actual open source package ecosystems. For instance, matching a vulnerability such as a CVE to a package name and set of versions in a package manager is difficult to do in an automated way using existing mechanisms such as CPEs.
- Can be used to describe vulnerabilities in any open source ecosystem, while not requiring ecosystem-dependent logic to process them.
- Is easy to use by both automated systems and humans.
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.
- Version enumeration (for non-SemVer ecosystems where supporting version enumeration code exists)
- Git commit to tag mapping
Both of these 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.
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.
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.
More information about how to download the database is available here.
OSV strives to provide reliable vulnerability information to our users. To support that goal, target the following service level objectives:
- Availability, website and API: 99.9% measured on a 7 day rolling window.
- Latency, website and API: P50 ≤ 300ms, P90 ≤ 500ms, P95 ≤ 1s, that is 50% of requests will be faster than 300ms, 90% of requests will be faster than 500ms, and 95% of requests will be faster than 1s.
- Data Freshness: Data sources no more than 15 minutes stale, 99.5% of the time.
OSV is completely open source!
- The infrastructure code is available here
- OSV-Scanner code is available here
- The OSV schema spec is available here
If you have any questions, please feel free to create an issue!
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.
No. Currently there is not a limit on the API.