OSV.dev: The Free Vulnerability Database You Should Be Using
OSV.dev: The Free Vulnerability Database You Should Be Using
The system that tracks every known software vulnerability almost went dark in April 2025.
MITRE's CVE Program, the 25-year-old index that every scanner, every SBOM tool, and every security team depends on, came within 17 hours of losing its federal funding. CISA forgot to renew the contract. They scrambled an 11-month emergency extension at the last minute.
That should scare you. What should scare you more: the backup system, NIST's National Vulnerability Database, has been broken for over a year.
NVD Is Drowning
As of Q3 2025, more than 18,000 CVEs sat in NVD's backlog waiting for analysis. In May 2024, 93.4% of new vulnerability submissions were still unprocessed. NIST's budget got cut 12% while CVE submissions jumped 38% year-over-year (40,009 in 2024 vs 28,961 in 2023). Submissions have increased 263% between 2020 and 2025.
The backlog is still growing. Q1 2026 submissions are running about 33% higher than Q1 2025.
This matters because NVD enrichment is what gives CVEs their CVSS scores, affected version ranges, and CPE entries. Without that enrichment, a CVE is just a number and a description. Your scanner can't match it to your dependencies. Your security team can't prioritize it. A 2025 Tenable Research report found that 60% of incidents involved vulnerabilities where patches had existed for over a month. Patch lag kills more than zero-days, and a broken NVD makes patch lag worse.
Enter OSV.dev
OSV.dev is Google's open-source vulnerability database. It's free, it's API-accessible, and it doesn't wait for NIST analysts to do anything.
Instead of relying on one source, OSV aggregates from 24 data sources across 30+ ecosystems: GitHub Security Advisories, PyPA, RustSec, Go's vuln database, and yes, NVD itself. When a Go maintainer files a security advisory, OSV picks it up. When RustSec publishes, OSV picks it up. It doesn't sit in a queue.
The key difference: OSV entries include machine-readable affected version ranges. Not "versions before 2.3.1 may be affected" in a text blob. Actual semver ranges your tooling can parse.
It also tracks malicious packages (the MAL-* advisories). NVD doesn't do this at all. If someone publishes a typosquatted reqeusts package to PyPI, OSV knows about it. NVD doesn't.
OSV-Scanner V2
In March 2025, Google shipped OSV-Scanner V2. It's the CLI tool that queries the OSV.dev database. Apache 2.0 licensed, no account required, no API key needed for basic use.
Install it:
# Go install
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest
# Or grab a binary from GitHub releases
curl -L https://github.com/google/osv-scanner/releases/latest/download/osv-scanner_linux_amd64 -o osv-scanner
chmod +x osv-scanner
Scan a project:
$ osv-scanner scan --recursive ./my-project
Scanned 14 lockfiles, found 847 packages
3 vulnerabilities found
GHSA-xxxx-yyyy-zzzz | HIGH | lodash < 4.17.21
GHSA-aaaa-bbbb-cccc | MEDIUM | express < 4.19.2
MAL-2025-1234 | HIGH | colors-utils (malicious package)
That last one is a malicious package detection. Your npm audit won't catch that.
Container Scanning
V2 added layer-aware container scanning. It tells you which Docker layer introduced each vulnerability, not just that the vulnerability exists somewhere in the image.
$ osv-scanner scan --docker myapp:latest
Layer 1 (ubuntu:24.04):
CVE-2025-1234 | MEDIUM | libssl3 < 3.0.15
Layer 3 (npm install):
GHSA-xxxx-yyyy-zzzz | HIGH | jsonwebtoken < 9.0.3
If you're an agency managing 20 client sites on Docker, you can scan them all with one tool. For free. No vendor contract, no per-seat license.
Guided Remediation
This is the feature most people don't know about. Instead of dumping a wall of CVEs on you, osv-scanner fix suggests specific version upgrades ranked by impact.
$ osv-scanner fix --non-interactive --strategy=in-place -L package-lock.json
3 vulnerabilities can be fixed by upgrading:
jsonwebtoken 8.5.1 -> 9.0.3 (fixes 1 vuln, 0 breaking changes expected)
express 4.18.2 -> 4.21.0 (fixes 1 vuln, 0 breaking changes expected)
1 vulnerability requires manual review:
MAL-2025-1234: colors-utils is a known malicious package. Remove it.
For a 3-person dev shop without a dedicated security engineer, this turns vulnerability management from "overwhelming spreadsheet" into "here are your 4 highest-impact upgrades." Guided remediation currently supports npm and Maven, with more ecosystems coming.
GitHub Actions Integration
Add vulnerability scanning to every PR in under 10 minutes:
# .github/workflows/osv-scan.yml
name: OSV Scan
on:
pull_request:
branches: [main]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: google/osv-scanner-action/osv-scanner-action@v2
with:
scan-args: |-
--recursive
./
That's it. Every PR gets scanned. No API key, no license file, no vendor onboarding call.
Where OSV.dev Falls Short
I'd be lying if I said OSV.dev replaces everything. It doesn't.
Open-source only. If your stack includes commercial CMS plugins, proprietary hosted APIs, or closed-source dependencies, OSV.dev is blind to those. NVD, for all its dysfunction, covers both open-source and commercial software. The realistic play is OSV.dev as your primary scanner for open-source deps, supplemented by NVD or a commercial tool for the rest.
No native CVSS scoring. OSV entries include severity ratings from upstream sources, but they don't always have CVSS vectors. If your compliance workflow requires CVSS scores, you'll need to cross-reference with NVD or another source.
Security literacy required. A developer who doesn't know the difference between a transitive dependency vulnerability and a direct one can get buried by scan results. The guided remediation feature helps here, but it only covers npm and Maven so far.
The Bigger Picture
The era of one vulnerability database to rule them all is ending. MITRE almost died. NVD can't keep up. The EU launched EUVD as a hedge. The CVE Foundation was created as a nonprofit backup for MITRE.
OSV.dev's architecture, pulling from 24+ distributed sources instead of relying on one central authority, is how this problem gets solved. It's not a government-funded program that can get defunded overnight. It's backed by Google and the OpenSSF, with data flowing in from dozens of independent security teams.
SBOM mandates are accelerating this. US Executive Order 14028 and the EU Cyber Resilience Act both push supply chain transparency requirements. OSV-Scanner natively consumes CycloneDX and SPDX SBOMs:
$ osv-scanner scan --sbom cyclonedx.json
If you need to demonstrate supply chain security to an enterprise client, this is the cheapest path to compliance.
How Vekt Fits In
Full disclosure: Vekt, our supply chain threat intelligence scanner, queries OSV.dev as one of its primary data sources. When Vekt scans your lockfiles across 12 ecosystems and 22 lockfile formats, it's pulling CVE and MAL-* advisories from OSV.
We built on OSV.dev because the data is open, the API is reliable, and the version-range matching is machine-readable. The same reasons you should be using it directly if you're not already.
Vekt adds trust scoring, a browser extension for package registry pages, and an LSP server for in-editor alerts. But OSV-Scanner on its own is a solid starting point if you're currently running nothing.
Get Started
Five minutes. That's all it takes.
# Install
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest
# Scan your project
osv-scanner scan --recursive .
# Get fix suggestions
osv-scanner fix --non-interactive --strategy=in-place -L package-lock.json
# Generate an HTML report
osv-scanner scan --recursive --format html -o report.html .
The HTML report is interactive and filterable. Open it in a browser, share it with your team, attach it to a client proposal. No vendor watermark, no "upgrade to see full results" paywall.
NVD might catch up someday. MITRE's funding might stabilize. But "might" and "someday" aren't a security strategy. OSV.dev works now, it's free, and it's not going anywhere.
Stop waiting for the government to fix vulnerability tracking. Scan your deps.