OSV, at osv.dev, helps developers find known vulnerabilities in third-party open source dependencies. It aggregates vulnerability databases that use the OpenSSF vulnerability format, offers an API, and has a first-party scanner. It is a good second opinion when you audit a project with your package manager's own tool.
What OSV does
According to the project documentation, OSV aggregates databases that publish in the OpenSSF format. It also adds infrastructure that checks affected versions through bisection and version analysis, so each entry reflects more accurately which versions are affected. That matters because version ranges in raw advisories are sometimes imprecise.
Because many ecosystems publish in a common format, one query can cover packages from different languages. That is useful for polyglot projects and for learning.
The pieces
| Piece | What it is |
|---|---|
| OSV.dev | The aggregated database and website |
| The API | Lets you query for known vulnerabilities by version number or commit hash, including a query endpoint |
| OSV-Scanner | The first-party tool that uses the OSV.dev data through its API |
The project page lists the API endpoints but sends you to the API documentation for request details, so read those before you script anything.
A practice exercise
- Take the practice project from our dependency scanning home lab.
- Run your ecosystem's audit command and save the result.
- Run OSV-Scanner on the same folder and save that result.
- Make a table of package, version and advisory ID for each tool.
- For each difference, open the advisory and work out why one tool reported it and the other did not.
Common reasons include different source databases, different handling of version ranges, and whether the tool reads your lock file or your installed environment.
Why a second source helps
No single feed is complete or perfectly timely. When two sources disagree, that is information. It tells you to read the advisory yourself rather than trust a count. This is also a good interview talking point: you can explain why you run more than one check and how you reconcile them.
Limits to remember
Matching a package and version to a record says nothing about whether your code uses the vulnerable function. It also cannot see flaws nobody has published. Treat results as leads to investigate. For prioritization, see our post on what fix available means.
What to write in your notes
After each run, record the date, the tool version, the files it read and the number of findings. Advisory data changes daily, so a result without a date is hard to interpret later. When you rerun a month on, compare the two runs and note which entries are new. That teaches you how fast data moves and why a clean result today is a statement about today only.
Where Safeguard fits
Safeguard also does SBOM and dependency scanning, and a free scan is a convenient third data point for your comparison table.
Quick check
Is OSV a scanner or a database?
Both exist. OSV.dev is the aggregated database and API, and OSV-Scanner is the tool that uses it.
Why would two tools disagree on the same project?
They may use different advisory sources, match versions differently, or read different files.
Sources
Last reviewed: 19 October 2026.
