OSV.dev website, Open Source Vulnerabilities, distributed vulnerability database, open-source security advisories, package ecosystems, OSV schema, API queries, OSV-Scanner, dependency risk, and WHOIS domain data

OSV.dev

OSV.dev is an open-source vulnerability database and API that helps developers find known vulnerabilities in open-source packages, commits, lockfiles, SBOMs, and container images.

Core purpose

OSV.dev aggregates open-source vulnerability records and offers search, an API, scanner tooling, and data organized with the OSV schema.

Official domain

osv.dev is the official website for the Open Source Vulnerabilities database and related documentation.

Domain registered

November 16, 2020

The official OSV.dev logo used as the brand image for the open-source vulnerability database website page.View official OSV.dev logo

What OSV.dev is

OSV.dev official site describes OSV as a distributed vulnerability database for open source. It collects vulnerability records from multiple ecosystems, presents them through a searchable website, and exposes an API for querying known vulnerabilities by package version or commit hash. The project is designed for dependency security work. Instead of treating every advisory as equally relevant, OSV focuses on precise affected-version data so developers and tools can decide whether a specific package, version, commit, lockfile, SBOM, or container image is affected.

Schema and data sources

OSV records use the OpenSSF OSV format, a structured data model for describing vulnerabilities in ways that map to open-source package ecosystems, versions, and commits. The homepage lists ecosystems such as npm, PyPI, Maven, Go, RubyGems, Packagist, crates.io, Debian, Ubuntu, Alpine, and more. The service acts as an aggregator for vulnerability databases that have adopted the format. That gives security tools a common way to read advisories from different communities without writing a custom parser for every source.

API and search workflows

OSV.dev provides an API for querying vulnerabilities by commit hash or package version. Developers can also search the website directly when they need to inspect a vulnerability entry, understand affected ranges, follow references, or compare advisories across ecosystems. The API matters because dependency checks often happen inside automation. Continuous integration, software composition analysis tools, build systems, and custom security scripts can query OSV data without requiring a human to browse each advisory manually.

OSV-Scanner and remediation

OSV-Scanner is the first-party tool that uses OSV.dev data. The official site shows workflows for scanning lockfiles, SBOMs, directories, container images, and GitHub workflows, plus guided remediation commands for some package-manager files. A scanner does not replace judgment. It narrows the field by identifying known vulnerabilities that match project dependencies, then maintainers still need to evaluate exploitability, upgrade paths, compatibility, and deployment risk.

Open-source infrastructure

The OSV.dev infrastructure is open source in the `google/osv.dev` repository. The documentation says the repository contains the infrastructure code that serves the website and API, and the homepage invites users to create issues for ideas or questions. That open development model is important for security infrastructure because data quality, schema choices, ecosystem coverage, and tooling behavior all affect how teams respond to vulnerability reports.

Who uses OSV.dev

OSV.dev is used by open-source maintainers, application security teams, dependency-management tools, CI/CD workflows, package ecosystem operators, software composition analysis vendors, developers reviewing upgrades, and researchers comparing vulnerability data across ecosystems.

Why it matters

Open-source security depends on accurate mapping between advisories and the exact versions or commits that are affected. OSV.dev matters because it gives ecosystems and tools a shared structure for that mapping, reducing noisy alerts and helping teams focus on vulnerabilities that actually touch their software. It also supports automation. A common API and schema let security checks happen earlier in development, in pull requests, scheduled scans, release pipelines, and container workflows.

WHOIS domain data

Data pulled: May 24, 2026View current WHOIS record

Domain: osv.dev
WHOIS source note: The Who.is WHOIS lookup did not expose a traditional WHOIS data table; the visible domain registration fields below are from the Who.is RDAP view for the same domain.
IP address: 34.49.235.131
Registrar: Markmonitor Inc.
Registrar handle: 292
Contact URI: https://www.markmonitor.com/contact-us/
Created: November 16, 2020
Updated: January 11, 2024
RDAP database updated: May 23, 2026
Expires: November 16, 2030
Nameservers: ns-cloud-a1.googledomains.com (216.239.32.106); ns-cloud-a2.googledomains.com (216.239.34.106); ns-cloud-a3.googledomains.com (216.239.36.106); ns-cloud-a4.googledomains.com (216.239.38.106)
Domain status: client delete prohibited, client transfer prohibited, client update prohibited
Contact privacy: The visible Who.is RDAP summary shows a domain contact URI at https://domains.markmonitor.com/whois/contact/osv.dev; registrant personal details are not displayed.

Key concepts

OSV schemaA structured format for vulnerability records that maps advisories to affected packages, versions, and commits.
Affected rangeThe version or commit span in which a package is vulnerable.
EcosystemA package or distribution community, such as npm, PyPI, Maven, Go, or Debian.
SBOMA software bill of materials, often scanned to understand what components appear in a build or image.

Common workflows

Search OSV.dev for a vulnerability by package, ecosystem, advisory ID, or related identifier.
Query the API from a security tool or CI workflow by package version or commit hash.
Run OSV-Scanner against lockfiles, SBOMs, directories, container images, or GitHub workflows.
Review references and affected ranges before planning remediation.

Common misconceptions

OSV.dev is not only a website; it also provides an API, schema, database infrastructure, and scanner tooling.
A vulnerability match should be investigated, because real risk depends on affected code paths, deployment context, and available fixes.
OSV data aggregates many sources, so ecosystem coverage and record quality can vary by source and package community.

Open questions

How can vulnerability databases reduce false positives without hiding important risk?
Which fields should every ecosystem provide to make advisories more actionable for automated tools?
How can maintainers communicate exploitability, fix availability, and migration cost in a structured way?