Security vulnerabilities in open-source dependencies are like background radiation, mostly ignorable, until they’re not. Since we are currently working on vulnerability detection research, today, I decided to see how much trouble I could get into by poking around Google’s Open Source Vulnerabilities database and its scanner.
Spoiler: not much. But it’s interesting trouble.
What is OSV?
OSV is Google’s attempt to make sense of the mess that is vulnerability reporting. You give it a dependency, say, Flask 2.0.1, and it tells you if it’s known to be a dumpster fire.
The data is normalized across ecosystems (npm, PyPI, Go, etc), so it doesn’t matter whether you write JavaScript, Python, Rust, or Go: your dependencies are all equally broken.
There’s a REST API for querying it. There’s also a CLI tool. And yes, both are as unglamorous and utilitarian as you’d expect.
The API: A Surprisingly Honest Conversation
The first step: ask the OSV API if a package is vulnerable. No tokens, no rate limits (that I could find). Just JSON in, JSON out.
curl -X POST https://api.osv.dev/v1/query -H 'Content-Type: application/json' -d '{
"package": {
"name": "flask",
"ecosystem": "PyPI"
},
"version": "2.0.1"
}'The response looks like this:
It doesn’t try to be clever. It tells you exactly what’s wrong, and then stops talking.
The Scanner: Letting a Tool Judge Your Code
Next: the osv-scanner. This is a Go CLI tool that scans your project via lockfiles, SBOMs, or raw directories, and tells you how many of your dependencies are already known to be bad ideas.
Install it like this:
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latestAnd run it on something depressing:
osv-scanner scan source -r /path/to/your/dirYou’ll get a list of vulnerabilities that will, depending on your maturity as a developer, either be a wake-up call or just another Tuesday.
You can also scan for container:
osv-scanner scan image my-image-name:tagNow you know everything that’s broken all this time.
Remediation: Letting the Tool Tell You How to Fix It
You’ve scanned your project. The scanner has stared into its soul and spat out a list of vulnerabilities. Now it’s time to fix them, so what happens next?
Good thing is that they not only gives you bad news but they provide the cure.
OSV‑Scanner includes a feature called guided remediation, a bit like a patient colleague handing you the needle and thread:
- It examines your
package.json/package-lock.json(or Mavenpom.xml). - It analyzes the transitive dependency graph, so you don’t blindly upgrade nested packages and break the world. It prioritizes upgrades that will knock out the most vulnerabilities with the least change. You can filter by severity, dependency depth, or whether it’s prod vs dev and even choose between.
This isn’t magic. It’s math: figure out which upgrade gives the biggest “bang for your byte” and offer it in a CLI or (in interactive mode) a simple UI .
To try it for npm:
osv-scanner fix --non-interactive \
--strategy=in-place \
-L path/to/package-lock.jsonOr go interactive for more control:
osv-scanner fix \
-M path/to/package.json \
-L path/to/package-lock.jsonFor Maven:
osv-scanner fix --non-interactive \
--strategy=override \
-M path/to/pom.xmlYou’ll get a list of proposed changes, each designed to resolve the most vulnerabilities without wreaking havoc.
What Limits to Expect
Currently, npm and Maven are the only ecosystems with guided fixes, though support is expanding. Some features are labeled experimental like in-place Maven changes or interactive screens, so expect some updates.
Last words
The OSV ecosystem is clean, practical, and deeply pessimistic about the state of software security exactly as it should be. It fix your code for you, but for now, only npm and Maven.
But, since we are currently working on code vulnerability detection framework, this would be useful for us. 🙂