OSV.dev

OSV.dev is an open-source vulnerability database and triage platform built by Google that provides precise, version-aware vulnerability data for open source packages. Unlike generic CVE databases that describe vulnerabilities in prose, OSV maps each advisory directly to the affected package versions or commit hashes using a standardized machine-readable schema — enabling automated tools to determine exactly whether a specific installed version is vulnerable.

The platform aggregates advisories from GitHub Security Advisories, the Python Packaging Authority, RustSec, NVD, Alpine, Debian, Ubuntu, and more than 50 other ecosystems. All data is published under the open OSV schema adopted by OpenSSF and is freely accessible via a REST/gRPC API, bulk GCS data dumps at gs://osv-vulnerabilities, and a web UI at osv.dev.

Behind the scenes, OSV runs on Google Cloud Platform using a polyglot architecture: Python services handle the API layer, import pipeline, and core vulnerability processing, while Go powers the binary analysis indexer, NVD CVE converters, and API bindings. Workers deployed on GKE perform bisection analysis on git repositories to pinpoint when a vulnerability was introduced and fixed — producing version ranges that are more accurate than what upstream advisories report.

OSV.dev is also the data backbone for first-party tools like osv-scanner and is consumed by Trivy, Dependency-Track, pip-audit, Renovate, and the OSS Review Toolkit, making it a foundational piece of the open source supply chain security ecosystem.

What You Get

• OSV Schema - A standardized JSON format co-developed with OpenSSF that maps each vulnerability to exact package versions or git commit hashes, with fields for affected ranges (introduced/fixed/last_affected), severity (CVSS), and package identifiers using PURL syntax.
• REST/gRPC API - A public API at api.osv.dev/v1 supporting queries by package+version (to get all matching vulnerabilities) and by commit hash (for git-based analysis), with batch query support for up to 1000 packages per request.
• GCS Data Dumps - Complete vulnerability database exports at gs://osv-vulnerabilities organized by ecosystem, updated continuously, allowing offline analysis, air-gapped environments, and custom database builds without rate limits.
• Web UI at osv.dev - A searchable frontend for browsing and querying the vulnerability database by package name, CVE ID, or ecosystem, with detailed per-advisory pages showing affected versions, severity, and references.
• Bisection Workers - Background GKE workers that automatically bisect git repositories to determine the exact commit that introduced or fixed a vulnerability, improving the accuracy of affected version ranges beyond what upstream advisories report.
• Multi-ecosystem Ecosystem Versioning - Language-specific version comparison libraries covering PyPI, npm, Go, Maven, RubyGems, Debian, Alpine, Hackage, Hex, NuGet, and 40+ more, each implementing package-manager-native version ordering for accurate impact determination.
• DetermineVersion API - An experimental gRPC endpoint that infers the version of C/C++ software in binaries by hashing file contents and matching against an indexed database — enabling SCA for languages without embedded version metadata.

Common Use Cases

• CI/CD dependency scanning - A platform team integrates the OSV API into their GitHub Actions workflow to query all lockfile dependencies (npm, PyPI, Go) against OSV on every pull request, blocking merges when a dependency version matches a known vulnerability’s affected range.
• Enriching SBOM workflows - A security engineering team feeds their CycloneDX SBOMs into Dependency-Track or GUAC, which queries OSV in the background to annotate each component with CVE status, CVSS scores, and fix versions for remediation prioritization.
• Building a custom vulnerability scanner - A startup building a supply chain security product uses OSV’s bulk data dumps to populate their own database, ingesting the full OSV schema nightly and layering their proprietary risk scoring on top of the standardized advisory data.
• Distributing advisories for a Linux distro - Alpine Linux and Debian security teams publish their advisories in OSV format, ensuring their package-specific version data is consumable by any OSV-compatible scanner without requiring custom integrations per distro.
• Binary SCA for C/C++ projects - A firmware security team uses the DetermineVersion API to identify library versions embedded in compiled binaries where no package manager manifest exists, submitting file content hashes to get back probable version matches and associated CVEs.

Under The Hood

Architecture OSV.dev is a well-structured service-oriented monorepo deployed on Google Cloud Platform, separating concerns into distinct layers: a gRPC API server, background GKE workers for bisection and impact analysis, a data importer pipeline, and ecosystem versioning libraries shared across services. The importer uses an asynchronous publish-subscribe pattern via Cloud Pub/Sub, with Cloud Datastore serving as the authoritative shared state layer. The Flask-based website proxy sits above the gRPC backend, preserving clean transport separation. Configuration-driven source definitions in YAML allow new vulnerability feed integrations without code modifications, and the bisection workers run inside gVisor-sandboxed Docker containers for safe execution of untrusted repository analysis.

Tech Stack The system is a deliberate polyglot architecture — Python 3.13 runs the API server (a gRPC servicer wrapped in Flask for HTTP), importers, and the core OSV library, while Go powers the vulnfeeds CVE converter, shared CLI tools, and the DetermineVersion indexer. Cloud Datastore via Python NDB is the primary store; Cloud Pub/Sub handles async work distribution; GCS provides public data dump storage; Cloud Run hosts both the API and website services behind Cloud Endpoints and Cloud Load Balancing. Protocol Buffers define all service contracts with auto-generated bindings in both languages. Deployment is managed via Terraform for infrastructure, Cloud Build for CI/CD pipelines, and Docker images with gVisor isolation for GKE worker pods.

Code Quality The codebase has comprehensive test coverage across both languages, with dedicated test files co-located alongside each module covering unit, integration, and edge cases including mock gRPC servers and Datastore emulator tests. Error handling is explicit and structured — custom exception hierarchies, GCP Cloud Logging integration with structured fields, and configurable retry logic with exponential backoff for storage and pubsub operations. Python type hints are enforced via mypy with mypy-protobuf for proto-generated code, while Go benefits from static typing natively. Code formatting is enforced by yapf (Python) and gofmt (Go), with pylint and continuous linting in Cloud Build pipelines.

What Makes It Unique The DetermineVersion API is genuinely novel engineering — it infers vulnerable version ranges in compiled C/C++ binaries by hashing file contents into buckets and matching against an indexed database of known library versions, addressing a fundamental gap in SCA tooling for languages without package managers. The coarse versioning system normalizes incompatible version schemes (Debian epoch notation, semver pre-releases, Alpine APK version strings, Maven qualifiers) into a unified comparable index enabling precise cross-ecosystem impact analysis. The OSV schema itself is an industry-level contribution, adopted by GitHub Security Advisories, OpenSSF, and the Python Packaging Authority as the standard format for machine-readable vulnerability advisories. The bisection worker infrastructure that automatically determines exact introduced/fixed commits from upstream git history adds a layer of accuracy that static CVE databases simply cannot provide.

Self-Hosting

OSV.dev is released under the Apache License 2.0, one of the most permissive open-source licenses available. This means you can use, modify, and distribute the software freely — including for commercial purposes — without any copyleft obligations on your own code. You are free to self-host the entire OSV infrastructure, build proprietary tooling on top of the OSV API, or redistribute modified versions under any license you choose, provided you retain the original copyright and license notices.

Running OSV.dev yourself is a substantial operational undertaking. The production deployment spans multiple Google Cloud services: Cloud Datastore for the vulnerability data store, GKE clusters for bisection and impact analysis workers, Cloud Run for the API and website services, Cloud Pub/Sub for task distribution, GCS for data dumps, and Terraform-managed infrastructure across all of these. You would need deep GCP expertise, active management of GKE workloads, and operational ownership of Datastore indexing, Cloud Build pipelines, and Docker image lifecycle. The bisection workers run untrusted code in gVisor sandboxes, adding another operational dependency. For most organizations, the practical self-hosting scenario is consuming the public data dumps or API rather than running the full infrastructure stack.

Google operates the production OSV.dev service as a free public good with no announced SLA for the API, no tiered support offering, and no enterprise licensing model — it is a Google Open Source Security Team project. This means there is no managed upgrade path, no dedicated support channel beyond GitHub issues and the osv-discuss mailing list, and no guaranteed uptime commitment. Organizations requiring SLAs, dedicated support, or managed ingestion pipelines for private vulnerability feeds would need to build those capabilities themselves or use a commercial SCA vendor (such as Snyk, Mend, or GitHub Advanced Security) that consumes OSV data as an input alongside their own proprietary advisory coverage.