.png)
In today’s interconnected software landscape, developers build applications that lean heavily on open source dependencies. This reliance offers speed, flexibility, and access to battle-tested code, but it also introduces a significant surface area for security vulnerabilities. Vulnerabilities in popular packages like Log4j, OpenSSL, or even transitive dependencies buried deep within a package tree have taught the developer community one vital lesson: you are only as secure as your weakest dependency.
To address this challenge at scale, Google introduced OSV (Open Source Vulnerabilities), a comprehensive, structured, and developer-first vulnerability database and ecosystem. Unlike traditional tools that offer noisy, inconsistent, and often vague results, OSV delivers precise vulnerability detection, ecosystem-specific clarity, and developer-oriented remediation guidance. It fundamentally transforms how we think about and handle secure dependency management in modern software projects.
This blog will take you deep into how OSV works, why it matters, how to integrate it into your development workflow, and how to build an automated, secure, and resilient open-source supply chain.
The average JavaScript project has over 1000 dependencies, many of which are deeply nested transitive packages. Developers often install libraries that depend on other libraries, leading to vast dependency trees that are hard to inspect manually.
In Python, packages installed via pip often bring in a host of ancillary packages, each with their own versioning and potential vulnerabilities. The same is true for Java’s Maven projects, Golang’s modules, or even compiled binaries built from C/C++.
Developers don’t just write code, they assemble code.
But every added dependency becomes a potential liability. From zero-day vulnerabilities to unpatched issues and even compromised maintainers, the attack surface is growing. Tools like Snyk, Dependabot, and NVD-based scanners attempt to surface vulnerabilities, but often generate noise and lack deep integration into developer workflows.
That’s where OSV steps in.
OSV (Open Source Vulnerabilities) is a vulnerability database and scanning ecosystem designed by Google. It consolidates advisories across many ecosystems, structured around a universal format optimized for developers. It includes an API, command-line scanner, and integration tools.
Key goals of OSV:
Unlike generic CVE databases, OSV focuses on version-aware reporting. It doesn’t just tell you a package might be vulnerable, it tells you this specific version you use is vulnerable, and this is the patch.
Traditional vulnerability feeds often lack precision. A package name might be flagged as vulnerable without specifying which versions are affected. Developers then waste hours chasing false alarms, investigating packages they don’t even use.
OSV uses a structured schema that maps vulnerabilities to specific commit hashes, semantic versions, and affected ranges. This lets scanners like osv-scanner identify only those vulnerabilities that affect your exact dependencies.
OSV defines a clear, consistent JSON schema for vulnerability advisories. This format captures:
By normalizing data across ecosystems, OSV makes it possible to compare and query vulnerabilities consistently, whether you're working with a Java project or a Docker container.
OSV supports a wide array of package ecosystems:
This means your backend services, CLI tools, frontend packages, and containerized applications can all be scanned and secured with the same system.
Installing the osv-scanner CLI tool is simple. It is distributed as a Go binary, or you can use precompiled releases. Installation is quick, light, and requires no external dependencies.
go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest
Once installed, you can immediately scan local directories, lockfiles, or even container images.
To scan a directory recursively for known vulnerability files (like package-lock.json, go.sum, requirements.txt):
osv-scanner -r ./my-project/
The scanner detects supported files, parses package versions, and matches them against OSV’s advisory database in real-time. The output is developer-friendly, providing:
You can also scan Docker images:
osv-scanner -D my-image:latest
It will analyze installed packages inside the image layers and detect vulnerable versions from OS distributions or custom binaries.
The fix command analyzes your dependency graph and suggests minimal upgrades to eliminate vulnerabilities. This prevents you from blindly upgrading your entire dependency tree and breaking compatibility.
osv-scanner fix --lockfile=package-lock.json --strategy=in-place
There are two remediation strategies:
This is essential for enterprises where stability and backwards compatibility matter as much as security.
You can integrate osv-scanner into your pipelines:
- uses: google/osv-scanner-action@v1
with:
path: ./my-project/
This ensures:
Scheduled scans can also be configured to catch new disclosures that affect previously safe versions.
Some vulnerabilities only pose a threat if the vulnerable code path is executed. OSV is working on reachability-based analysis, which will allow tools to determine whether vulnerable functions are even used in your application.
This reduces false positives and helps developers prioritize real threats.
Modern security isn’t just about CVEs, it’s about governance. OSV-Scanner includes license detection, allowing teams to identify incompatible or risky licenses (like GPL in commercial apps).
This helps engineering and legal teams ensure compliance while securing the codebase.
The scanner can detect which container image layer introduced a vulnerable package. This is crucial for DevOps and SRE teams who need to pinpoint base image versions or Dockerfile changes that introduced a threat.
OSV is already used by major open-source projects including:
These teams rely on OSV to prevent vulnerable dependencies from slipping into production releases.
Enterprise teams have used OSV to:
One tech lead at a fintech startup shared:
“We dropped Dependabot in favor of OSV. The signal-to-noise ratio is so much better. We only get alerted when there’s something that really matters.”
Lockfiles like package-lock.json, go.sum, or Pipfile.lock are essential. They let OSV match exact versions, enabling accurate vulnerability mapping. Never deploy without a locked dependency state.
Run scans on every PR and nightly. Set thresholds for severity. Fail builds on critical issues. This ensures security is part of your daily workflow, not an afterthought.
Let osv-scanner fix propose patches. Review them manually or in CI pipelines. Only update critical dependencies or deploy in staged environments first.
Containers are often overlooked. Scan your base images regularly. Rebuild and redeploy when security patches are released, even if your app code hasn’t changed.
OSV evolves fast. New ecosystems are being added regularly. Update your CLI tools and CI plugins to benefit from improved precision, coverage, and speed.
OSV is not just another scanner, it's a smarter, developer-focused way to manage security in open-source software. By prioritizing accuracy, ecosystem-awareness, and developer productivity, OSV enables teams to proactively protect applications without slowing them down.
Whether you're an open-source maintainer or managing enterprise services, OSV empowers you to:
Start using OSV today, and make secure dependency management a natural part of your software development lifecycle, not a painful afterthought.
.png)
