Installing and using osv-scanner: find CVEs in your dependencies

For: anyone who wants to check whether their app's dependencies hide known vulnerabilities (CVEs), especially "built it with AI's help, unsure about dependency safety." No attack steps here — only defense: inspecting your own footing (your own lockfiles).

1. What osv-scanner is

A Google-built open-source scanner written in Go. Its vulnerability data comes from OSV.dev, a cross-language open vulnerability database. The key difference from a language-specific tool like npm audit is breadth: it reads lockfiles across npm, PyPI (Python), Go, Rust, Maven (Java) and more.

The mechanism is simple: it lists the versions actually resolved in your lockfile, matches each package+version against OSV, and returns the relevant CVEs and fixed versions. The fact that it reads the lockfile, not the manifest (package.json's ^ floor) matters — it lines up with the principle of judging by the running version.

2. Install it

Pick whatever fits your OS and taste — all are officially supported.

If you'd rather install nothing and only use it in CI, run it straight from the Docker image.

# confirm it's installed
osv-scanner --version

3. Run it

You'll mostly either "recursively scan a whole directory" or "name a lockfile."

# scan the whole project recursively (auto-detects lockfiles)
osv-scanner scan -r ./
 
# name a lockfile (npm / pnpm / yarn, etc.)
osv-scanner scan -L pnpm-lock.yaml
 
# emit JSON (to feed CI or another tool)
osv-scanner scan -L package-lock.json --format json
 
# inspect a container image
osv-scanner scan image my-app:latest

Running it via Docker (no install required):

docker run --rm -v "$(pwd):/src" ghcr.io/google/osv-scanner:latest scan -r /src

Reading the output

For each hit you get the package name, the current version, the CVE/Advisory ID, and the fixed version. There's one job: bump to the fixed version or above, update the lockfile, and re-run to confirm it's gone. To dig into a CVE (severity, exploitation status), paste the ID into the CVE/KEV lookup to see CVSS and whether it's actively exploited (KEV) in one screen.

4. Make it continuous (wire it into CI / cron)

Running it once by hand is pointless. It works when it runs before every build or daily via cron. osv-scanner exits non-zero when it finds a vulnerability, so dropping it into a CI step stops the build the moment a dangerous dependency slips in.

5. Choosing between the tools

The right move isn't "always osv-scanner" — it's whatever is most natural for your setup.

In short, osv-scanner, pnpm audit, and Dependabot aren't competitors — they're different roles. Need cross-language breadth and no GitHub dependency? osv-scanner. Single npm? the bundled audit. GitHub-centric? Dependabot — and you can stack them. What matters is "always run at least one of them, automatically." Against supply-chain poisoning (like the Codecov breach or the xz-utils backdoor), continuous dependency checks are the first line of defense.

What this site does itself

This site runs its dependency self-audit via pnpm audit before every deploy plus a daily cron (high/critical fails the build and triggers an email). We didn't pick osv-scanner because this site keeps no repo on GitHub and its tree is single-npm — "free, no extra binary, no GitHub dependency" is already met by pnpm audit. That's the standard we wrote applied to ourselves, and it's part of the product's credibility. And if you just want to try it once, right now, with no install, we also ship a browser-only dependency vulnerability scanner (paste a lockfile, nothing leaves the page).

Read next

• Stack: Next.js CVE hygiene (judge by the running version, machine-monitor)
• Glossary: CVE · CVSS
• Incident: Codecov — supply-chain poisoning
• Tools: dependency scanner (browser-only) · CVE/KEV lookup