OSV, short for Open Source Vulnerabilities, is an open, distributed vulnerability database and data format built specifically for open source software, designed so that affected versions are expressed in precise, machine-matchable ranges rather than loose product strings. OSV has two parts that are easy to conflate: the OSV schema, a standardized data format for describing a vulnerability's affected packages and version ranges, and OSV.dev, a free aggregating database and API that collects advisories from many ecosystem sources into that common format. Its central design goal is to solve a long-standing problem with traditional vulnerability data, which is that determining "is my exact version of this exact package affected?" was historically a manual, error-prone task. OSV makes that determination something a scanner can compute automatically.
Why OSV matters for supply chain security
Automated dependency scanning is only as good as the affected-version data it matches against. Older data formats often described affected software in terms designed for operating systems and vendor products, which map poorly onto the reality of open source, where a vulnerability affects, say, versions of a named package from one release up to but not including a fixed release. Translating that into a reliable automated match required human normalization, which introduced delay and mistakes.
OSV attacks this directly by expressing affected ranges in the same ecosystem-native, version-aware terms that package managers use, keyed by the package's name and ecosystem. That means a scanner can take the exact versions from your lockfile and mechanically decide whether each one falls inside an affected range, with far fewer false positives and false negatives. Because open source dependencies dominate the modern attack surface, precise, automatable matching is foundational to practical supply chain security, and OSV is one of the key data sources that makes it work.
How OSV works
The OSV schema describes a vulnerability as a structured record: an identifier, a summary, references, and, most importantly, a list of affected entries. Each affected entry names a package and its ecosystem (such as npm, PyPI, Go, Maven, crates.io, or others) and specifies the version ranges that are vulnerable, typically as an introduced version and a fixed version, plus optionally an explicit list of affected versions. This range-based structure is what lets tooling answer version questions deterministically.
OSV.dev, the database, aggregates records from many upstream advisory sources that already publish in or are converted to the OSV format, including language and platform-specific advisory databases. It exposes this through an API that accepts a package and version, or a commit hash, and returns the matching vulnerabilities. Because the schema is open and the identifiers from contributing databases are preserved, a single flaw can be cross-referenced across sources, and the same record can carry both its OSV-style identifier and its corresponding CVE identifier where one exists.
Key points at a glance
| Aspect | What OSV provides | Why it helps |
|---|---|---|
| Schema | Standard format for affected ranges | Consistent, machine-readable data |
| Ecosystem keys | Package name plus ecosystem | Matches real package coordinates |
| Version ranges | Introduced and fixed versions | Deterministic version matching |
| Aggregation | Many advisory sources in one place | Broad open source coverage |
| Open API | Query by package, version, or commit | Easy scanner integration |
| Cross-references | Preserves CVE and source IDs | Correlate across databases |
How Safeguard uses OSV
Safeguard uses OSV-style, range-based data as a core matching layer because it aligns with how dependencies are actually resolved. Our software composition analysis takes the exact package coordinates and versions from your lockfiles and matches them against ecosystem-native affected ranges, so findings reflect your real resolved tree instead of a fuzzy product string. This precision is what keeps the signal-to-noise ratio high enough for developers to trust the results.
We combine that matching with reachability analysis, so a vulnerability whose affected range includes your version is prioritized by whether your code actually reaches the flawed function. SBOM Studio records the resolved versions and their identifiers so cross-referencing across OSV, CVE, and other sources is automatic, and Griffin AI uses the introduced-and-fixed range data to compute the smallest safe upgrade and open it as a reviewable pull request. The result is fast, accurate, ecosystem-aware detection and remediation.
Frequently Asked Questions
What is the difference between OSV and CVE? CVE is a system for assigning unique identifiers to vulnerabilities and publishing base descriptions. OSV is an open data format and database focused on open source, whose defining feature is precise, machine-matchable affected version ranges. They are complementary: an OSV record for an open source flaw often references the corresponding CVE identifier, while adding the version-range detail that makes automated matching reliable.
Is OSV the same as OSV.dev? Not exactly. OSV refers to the open schema (the data format) and the broader project, while OSV.dev is the specific free database and API that aggregates advisories in that format. In casual usage people say "OSV" to mean both, but the distinction matters: the schema can be used by many databases, and OSV.dev is one prominent implementation and aggregator.
Which ecosystems does OSV cover? OSV is designed to be ecosystem-agnostic and covers a broad range of open source package ecosystems by aggregating from source-specific advisory databases. Coverage spans major language ecosystems and platforms, with each record keyed by both the package name and its ecosystem so matches are unambiguous across the many places open source code is published.
Why is range-based version data better for scanning? Because it lets a tool decide, mechanically and without human normalization, whether a specific installed version is affected. Expressing vulnerabilities as an introduced version and a fixed version means a scanner can compare your exact lockfile versions against the range directly, which reduces both missed vulnerabilities and false alarms compared with matching against imprecise product identifiers.
Ready to match your exact dependency versions against precise vulnerability ranges? Create a free account at app.safeguard.sh/register and start scanning, then keep learning with the free Safeguard Academy.