osv-scanner for dependency and container vulnerability auditing

osv-scanner is Google's open-source dependency scanner that matches your project's packages against the OSV.dev vulnerability database for authorized security auditing, remediation guidance, and license compliance.

Tool	google/osv-scanner — official Go frontend to the OSV.dev vulnerability database and CLI interface to OSV-Scalibr
Category	Dependency vulnerability scanner (SCA)
Primary Use	Auditing source trees, lockfiles, SBOMs, and container images against OSV.dev advisories during authorized security reviews and CI pipelines
Safe Use	Purely defensive: designed for auditing your own code, dependencies, and images in authorized assessments, internal SDLC gates, and research labs; it never touches third-party systems
Telemetry Note	Sends package names, versions, ecosystems, and file hashes to the OSV.dev and deps.dev APIs; --offline mode with a locally downloaded database eliminates all network egress

osv-scanner occupies a specific and increasingly important niche in the defensive toolchain: it is the officially supported frontend to the OSV.dev vulnerability database and the CLI interface to Google's OSV-Scalibr extraction library. Rather than being yet another software composition analysis product, it is the reference implementation of an open data pipeline: it enumerates what your project depends on, feeds that inventory into a public advisory database, and returns a precise mapping of vulnerabilities to the exact versions you ship. The project carries over eleven thousand stars, is written in Go, and ships under the permissive Apache-2.0 license, which makes it trivially embeddable in CI pipelines and internal tooling without licensing friction.

The architectural decision worth noting first is the split between extraction and correlation. osv-scanner itself is a thin, polished CLI; the heavy lifting of parsing lockfiles, manifests, and container layers happens in OSV-Scalibr, an extensible library designed so new ecosystems can be added without touching scanner logic. This separation explains the breadth of coverage the README claims: eleven-plus language ecosystems and nineteen-plus lockfile types, spanning C/C++, Dart, Elixir, Go, Java, JavaScript, PHP, Python, R, Ruby, and Rust, along with package managers like npm, pip, yarn, maven, go modules, cargo, gem, composer, and nuget. If an ecosystem is missing, the maintainers explicitly invite feature requests, signaling that coverage is treated as a community roadmap rather than a closed product decision.

Basic usage is deliberately minimal. Running osv-scanner scan source -r /path/to/your/dir recursively walks a directory looking for recognizable dependency manifests such as package.json, go.mod, or pom.xml, then reports matching vulnerabilities. The README is careful to frame the current instructions as targeting the V2 beta, pointing V1 users to a separate repository and documentation set — a detail that matters operationally, because flag syntax and behavior differ between major versions and anyone scripting around the tool should pin their expectations accordingly. Installation follows the standard Go pattern: prebuilt binaries from the GitHub releases page are recommended, or go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest builds from source.

What elevates osv-scanner above naive version-matching scanners is its call-analysis capability. Instead of flagging every vulnerable dependency in your graph, it can determine whether a vulnerable function is actually reachable in your code, which directly attacks the false-positive problem that plagues SCA adoption. The README also highlights detection of vendored C/C++ code — a genuinely hard problem, since vendored sources carry no manifest at all — handled by matching file content against the database. For teams drowning in triage queues, reachability information is often the difference between a report that gets ignored and one that gets acted on.

Container scanning is a first-class feature, not an afterthought. The scan image subcommand performs layer-aware analysis of container images, detecting vulnerabilities in both operating-system packages and language-specific dependencies across base distros like Alpine, Debian, and Ubuntu, with language artifact support for Go, Java, Node, and Python. Layer awareness matters because remediation strategy differs depending on whether a vulnerable package arrived in the base image or was added by a later build step; a scanner that flattens the image loses that context. The invocation osv-scanner scan image my-image-name:tag fits naturally into registry-side or pre-deploy CI gates.

Beyond vulnerability matching, the tool doubles as a license compliance checker. The --licenses flag retrieves per-package license data from deps.dev, and the variant --licenses="MIT,Apache-2.0" enforces an allowlist in SPDX format, failing when a dependency falls outside the approved set. For organizations with legal review processes, this collapses two audit passes — security and licensing — into a single tool invocation, which is a pragmatic win for pipeline hygiene.

Privacy and egress behavior are documented with unusual candor, and this is the section defenders and compliance teams should read closely. During normal operation osv-scanner talks to the OSV.dev API for advisory lookups and to the deps.dev API for dependency resolution, container metadata, license data, and deprecation checks. The data transmitted includes package names, versions, ecosystems, and file hashes — never source code. The README also notes that when using native registries instead of deps.dev for resolution, queries may hit repo.maven.apache.org, registry.npmjs.org, or pypi.org. The disclosure is honest about a subtle leak vector: package names and versions from a private codebase constitute metadata that some organizations will not want leaving the perimeter.

That concern is answered directly by offline mode. The --offline and --download-offline-databases flags let you pull a local copy of the OSV database once and run all subsequent scans with zero network connectivity. For air-gapped environments, classified networks, or simply paranoid supply-chain postures, this converts osv-scanner from a cloud-dependent convenience into a fully local audit engine. It also has a defensive monitoring implication: blue teams can detect which mode an environment uses by watching for egress to the OSV.dev and deps.dev endpoints versus complete absence of outbound traffic during scans.

The most interesting feature, and the one carrying the sharpest warning label, is guided remediation — the fix command, currently experimental. It recommends package version upgrades scored by dependency depth, minimum severity, fix strategy, and return on investment, and supports strategies like in-place lockfile edits, relock, and Maven override across package-lock.json, package.json, and pom.xml. The README's warning is worth internalizing: running fix on untrusted projects is risky because it may drive the package manager to execute install scripts or follow external registry references. In other words, the remediation path re-introduces exactly the supply-chain execution risk the scanner exists to surface, so it should only ever be pointed at code you already trust — ideally inside isolated build environments.

The quality of the underlying data deserves its own analysis, because a scanner is only as good as its advisories. OSV.dev aggregates from open, authoritative upstream sources including GitHub Security Advisories, the RustSec advisory database, and Ubuntu security notices, and the OSV format itself stores affected-version ranges in a machine-readable schema that maps unambiguously onto a developer's dependency list. The README argues this yields more accurate and actionable notifications than closed-source advisory feeds, and the argument holds: open, contestable advisory data with structured version semantics is what enables the precise matching and reachability analysis the tool performs. Coverage even extends to GIT-ecosystem advisories, meaning commits of vulnerable library code are tracked as first-class entities.

Engineering posture signals are strong across the board. The README showcases an OpenSSF Scorecard badge, SLSA level 3 provenance attestation, continuous integration checks, and codecov tracking — a meaningful combination for a tool you will run inside your build pipeline, since supply-chain compromise of the scanner itself is a real threat model. SLSA 3 in particular means release artifacts carry verifiable build provenance, allowing paranoid consumers to confirm a binary was produced by the official build process rather than a substituted artifact.

In an authorized professional workflow, osv-scanner slots in as the open, scriptable foundation of dependency risk management: run it in CI on every pull request via scan source, gate image promotion with scan image, enforce license policy with --licenses, and triage what it finds using call analysis and guided remediation — keeping fix confined to trusted, sandboxed builds. It is a defensive instrument through and through, touching only your own artifacts and data, and its transparent data-egress documentation plus offline mode make it one of the few SCA tools suitable for even the most restricted environments. For anyone building an internal vulnerability management program on open components rather than commercial black boxes, it is close to a default choice.

Official project repository for google/osv-scanner.

Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.