OSV.dev: Google's Open Vulnerability Database, Its API, and the Service That Feeds It

What OSV.dev Actually Is

OSV.dev is not a single tool. It is a repository that contains the code for running the osv.dev website on Google Cloud Platform (GCP), plus a core Python library called `osv/` that powers most Python services. The README describes it as an 'open source vulnerability DB and triage service'. The problem it solves is the fragmentation of vulnerability data across many ecosystems: each package manager has its own advisory format, and there is no unified way to query them. OSV.dev provides a standardized schema and a public API to query vulnerabilities by package and version. The intended audience is developers and security teams who want to integrate vulnerability checking into their tooling, as well as researchers who need data dumps for analysis. The scanner, which is the most user-facing part, is actually in a separate repository, `google/osv-scanner`, but it is mentioned here because it uses the OSV API.

The Architecture: A GCP-Centric Monorepo

The repository is organized into several directories, each with a distinct role. The `gcp/` directory contains the services: `gcp/indexer` determines versions, `gcp/website` is the backend for the web interface, and `gcp/workers/` has Python workers for Vanir signatures and OSS-Fuzz. The `osv/` directory holds the core Python library, including ecosystem versioning helpers in `ecosystems/` and Datastore model definitions in `models.py`. The `go/` directory is a Go module with shared libraries and commands like `cmd/api`, `cmd/importer`, `cmd/worker`, and `cmd/exporter`. There is also `vulnfeeds/`, a Go module for converting NVD CVEs, with an Alpine feed converter and a Debian feed converter. This is a service-oriented architecture, but it is tightly coupled to GCP: the README lists Terraform and Cloud Deploy configs, Cloud Build YAMLs, and a Datastore index file. If you are not on GCP, running this repository yourself is a significant undertaking.

How the Data Flows: Indexer, Workers, and the API

The data flow is visible from the components. The indexer (`gcp/indexer`) determines versions, which likely means it maps package versions to commits or tags. The workers (`gcp/workers/`) include an OSS-Fuzz worker and a Vanir signatures worker, suggesting that vulnerability data is ingested from fuzzing and signature sources. The `cmd/importer` and `cmd/exporter` in the `go/` module handle importing and exporting data, likely to and from the Datastore. The API is exposed via `cmd/api`, and there are bindings in `bindings/` (currently Go only) for the OSV API. The README mentions data dumps available from a GCS bucket at `gs://osv-vulnerabilities`, which means you can get the entire database without using the API. This is a pull-based model: the OSV database aggregates vulnerabilities from multiple sources, normalizes them into the OSV schema, and serves them via the API or dumps. The scanner, in the separate repository, queries the API to check dependencies against this data.

Getting It Running: Commands and Config

The README gives one concrete command for local development: after cloning, you must run `git submodule update --init --recursive` to pull in submodules. This is a prerequisite for many local building steps. Beyond that, the README points to comprehensive documentation at `https://google.github.io/osv.dev` and API documentation at `https://google.github.io/osv.dev/api/`. There is no quick-start command for running the whole stack; the repository includes Terraform configs in `deployment/`, so deploying to GCP would involve `terraform apply` after configuring variables, but the README does not specify that command. For the scanner, you would need to go to the osv-scanner repository, which is not covered here. The practical takeaway: if you want to use OSV.dev as a service, you do not need to run this repository at all; you can use the hosted instance at `https://osv.dev` or the data dumps. If you want to run it yourself, be prepared to work with GCP infrastructure and submodules.

The Scanner: A Separate Tool with Specific Inputs

The README says the scanner is a Go-based tool that scans dependencies and checks them against the OSV database via the OSV API. It can scan various lockfiles, Debian Docker containers, SPDX and CycloneDX SBOMs, and git repositories. The scanner is in its own repository, `google/osv-scanner`, so the details of its usage are not in this README. This separation is a double-edged sword: it keeps the main repository focused on the backend service, but it means that anyone looking for a vulnerability scanner must find and evaluate a different project. The scanner's ability to handle SBOMs is notable, as that is a common format for supply chain security. However, the README does not specify which lockfile formats are supported, nor does it give example commands. If you are evaluating OSV.dev for scanning, you need to look at the scanner's own documentation, which is not provided here.

Limitations and Wrong Tool Cases

The most obvious limitation is the GCP dependency. The README lists Terraform, Cloud Deploy, Cloud Build, and Datastore as core components. If your infrastructure is on AWS or on-premises, running this repository would require significant rework. The PyPI Cloud Function in `gcp/functions` is explicitly noted as 'maintained, but not developed', which means it may not receive new features. That is a red flag if you rely on PyPI vulnerability publication. Another limitation: the scanner is a separate tool, so the main repository does not provide a ready-to-use scanning solution out of the box. Also, the data dumps are stored in a GCS bucket, which is a Google Cloud storage service; accessing them requires Google Cloud credentials or tools, which could be a barrier for non-GCP users. If you need a vulnerability scanner that is simple to install and run locally, OSV.dev (the repository) is the wrong tool; you should look at the scanner separately or consider alternatives.

Alternatives and How They Differ

The README lists community tools that use OSV, including Trivy, Dependency-Track, and pip-audit. These are not alternatives to OSV.dev itself, but they are alternatives for the scanning use case. Trivy, for example, is a comprehensive vulnerability scanner that scans container images, filesystems, and git repositories, and it can use OSV as a data source. The difference is that Trivy is a standalone scanner that you run as a binary or a container, whereas osv.dev is a database and API service; the scanner is a separate tool. Dependency-Track is a platform for component analysis that can ingest SBOMs and has its own vulnerability database, but it can also integrate with OSV. The key difference is that OSV.dev is a centralized data service, while Trivy and Dependency-Track are tools that consume data from multiple sources. If you want a self-contained scanner with a broad range of features, Trivy is a direct alternative to the osv-scanner, but it is not a replacement for the OSV database itself.

Maintenance and License Considerations

The project is licensed under Apache-2.0, which is permissive and allows commercial use, modification, and distribution, with the condition of retaining copyright notices. The repository is not archived, and the last push was in April 2026, with a recent release v0.1.3 in April 2026, indicating active maintenance. However, the maintenance is not uniform: the PyPI Cloud Function is maintained but not developed, and the README notes that community tools are not supported or endorsed by the core maintainers. For upgrade cost, the repository uses submodules, which means you need to manage those when pulling updates. The release history shows a pattern of roughly annual releases (v0.1.1 in September 2025, v0.1.2 in September 2025, and v0.1.3 in April 2026), so updates are not frequent, but they do happen. If you deploy this on GCP, you will need to track changes to Terraform configs and Cloud Build YAMLs, which can be a maintenance burden.

Editorial conclusion

Adopt OSV.dev if you need a centralized, open source vulnerability database with a public API and data dumps, and you are comfortable running a GCP-centric service. Do not adopt it if you need a lightweight, self-contained scanner; the scanner is a separate repository (osv-scanner), and the main repo is a full GCP deployment with Terraform, Cloud Build, and multiple Python/Go services. Before adopting, verify that your ecosystems are supported by the OSV schema, check the data dump format in the docs, and ensure you can manage submodules for local builds. The project is actively maintained (last push April 2026) under Apache-2.0, but the PyPI Cloud Function is 'maintained, but not developed', so confirm that component's status if you rely on it.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes