Open Source Vulnerability (OSV) Format

The Open Source Vulnerability (OSV) format is a standardised schema for representing vulnerability information, maintained by Google and hosted at osv.dev. OSV records describe which package versions are affected by a vulnerability with ecosystem-specific precision — specifying the exact version ranges in which the vulnerability is present and the first fixed version. This version-range model is more precise than the NVD CPE-based approach, which often has known inaccuracies for package-level matching. OSV data is provided for major open source ecosystems including npm, PyPI, Maven, Go, Rust (crates.io), Ruby Gems, NuGet, Debian, Alpine, and Android. The OSV schema is open and allows vulnerability databases from multiple sources to be published in a consistent, machine-readable format.

For manufacturers building CRA-compliant vulnerability management workflows, OSV provides a powerful complement to NVD/CVE data. The key advantage is precision: an OSV query for pkg:pypi/[email protected] returns only the vulnerabilities that specifically affect that version, using the OSV version-range data. NVD CPE-based queries for the same package often return false positives (CVEs with imprecise CPE data) and false negatives (CVEs missing CPE data). OSV-based vulnerability correlation against SBOM PURLs provides:

• Higher signal-to-noise ratio in vulnerability reports.
• Version-specific 'affected' vs 'fixed' information enabling rapid determination of whether an available fix resolves the vulnerability.
• Data aggregated from multiple sources (OSV, GitHub Advisory Database, GHSA) in a single query.

Google provides OSV-Scanner, an open-source command-line tool that takes an SBOM (CycloneDX or SPDX) or a lockfile as input and queries the OSV database for known vulnerabilities affecting the listed components. OSV-Scanner is designed to integrate into CI/CD pipelines for continuous vulnerability monitoring. For CRA compliance workflows:

• Run OSV-Scanner against the product SBOM on every build to detect new vulnerabilities disclosed since the previous scan.
• Include OSV-Scanner results in the technical documentation file as evidence of vulnerability monitoring.
• Use OSV-Scanner output to feed the vulnerability triage process, prioritising findings by CVSS score and EPSS data.
• Generate VEX statements for OSV findings that are assessed as not-affected in the product context.

OSV serves as an aggregator and re-publisher of vulnerability data from multiple sources. GitHub Advisory Database (GHSA) is the primary source for many npm, PyPI, and Go vulnerabilities. OSV imports GHSA data and republishes it in OSV format. CVE records from NVD are also mapped to OSV entries where precise version data is available. This means an OSV query may return both OSV-native records (e.g., GHSA-xxxx-xxxx-xxxx) and CVE-mapped records (e.g., CVE-2023-XXXXX), potentially providing more complete coverage than querying either source alone. Manufacturers should include OSV-based scanning alongside NVD-based scanning in their SBOM vulnerability management workflow to maximise coverage.