# OSV-Scanner: Google's Go frontend to the OSV vulnerability database > OSV-Scanner matches a project's dependency files against OSV.dev advisories, and the same binary also scans container images, checks licences and proposes version upgrades. It is a good fit for CI pipelines that want machine-readable output and an offline mode, and a poor fit if you need a commercial support contract. **google/osv-scanner** — Vulnerability scanner written in Go which uses the data provided by https://osv.dev - Repository: https://github.com/google/osv-scanner - Website: https://google.github.io/osv-scanner/ - Stars: 11,117 · Forks: 803 - Language: Go - License: Apache-2.0 - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/google-osv-scanner ## The dependency-to-advisory matching problem OSV-Scanner addresses A lockfile records exact versions. An advisory database records affected version ranges. Turning the first into a list of real problems is mostly a mapping exercise, and it is the part most teams get wrong by hand. OSV-Scanner is the officially supported frontend to OSV.dev, and the README describes it as a CLI interface to OSV-Scalibr that connects a project's list of dependencies with the vulnerabilities that affect them. The intended user is whoever owns dependency hygiene for a repository: a platform engineer wiring up CI, a maintainer who wants a local answer before opening a pull request, or a security engineer who needs to scan a container image without pulling in a commercial platform. The README lists C/C++, Dart, Elixir, Go, Java, JavaScript, PHP, Python, R, Ruby and Rust, with npm, pip, yarn, maven, go modules, cargo, gem, composer and nuget among the package managers. The design bet is on OSV.dev rather than a private advisory feed. The README argues that OSV format stores affected versions in a machine-readable way that maps precisely onto a developer's package list, and that advisories come from open sources such as GitHub Security Advisories, RustSec and Ubuntu security notices. That is the reason the tool can be accurate without a subscription, and also the reason its coverage tracks whatever those upstream sources publish. ## How OSV-Scalibr extraction feeds the OSV.dev lookup The scanning work is split in two. OSV-Scalibr, a separate Google library pinned in go.mod, walks the target and extracts package inventories. OSV-Scanner then matches those inventories against OSV.dev and renders the result. The repository layout reflects this: cmd/ holds the CLI entry point, internal/ and pkg/ hold the scanning and output logic, and the go.mod requires both github.com/google/osv-scalibr and osv.dev/bindings/go. That split matters when you evaluate coverage. A new lockfile format is usually an OSV-Scalibr extractor, not an OSV-Scanner feature, so support arrives through a dependency bump. The README points readers at the supported-languages-and-lockfiles page for the current list and asks for a feature request when something is missing. For source scans the README notes an optional call analysis mode, which checks whether a vulnerable function is actually reachable in the project. This is the difference between a finding you act on and a finding you mute. The same section mentions detection of vendored C/C++ code. Output formats are not enumerated in the README, but go.mod pulls in go-sarif, CycloneDX, go-pretty and glamour, which tells you SARIF, CycloneDX and terminal rendering are all in scope. Container scanning is layer-aware and covers OS packages on Alpine, Debian and Ubuntu, plus language artifacts for Go, Java, Node and Python. The README presents that as the supported matrix, and it is narrower than the source-scanning matrix, so an image built on another distribution is not covered by the documented list. ## Installing OSV-Scanner and running a first source scan The README does not embed install commands. It directs readers to the installation section of the documentation at google.github.io/osv-scanner/installation and to the GitHub releases page, and states that the recommended method is a prebuilt binary for your platform. The only install command the README gives is the Go one, which builds from source: ```bash go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest ``` Once the binary is on your PATH, the first real use is a recursive source scan. The README gives this example, and it walks the directory looking for supported package files such as package.json, go.mod and pom.xml: ```bash osv-scanner scan source -r /path/to/your/dir ``` Expect a list of vulnerabilities tied to the packages found. If you want the result in a form a code scanning dashboard can ingest, check the documentation for the output flags before wiring it into a pipeline, because the README shows only the default rendering. The second common entry point is a container image. The README's example is: ```bash osv-scanner scan image my-image-name:tag ``` For air-gapped or high-volume runs, the offline mode downloads a local copy of the database and then works without a network connection: ```bash osv-scanner --offline --download-offline-databases ./path/to/your/dir ``` The README states the database can also be downloaded manually. There is also a Dockerfile in the repository that builds the binary in a golang:1.27.1-alpine3.23 builder stage and copies it into an alpine:3.24 runtime with ca-certificates and git installed, which is the route to take if you would rather not install Go locally. ## Licence checking and guided remediation, and where the fix command stops being safe Two features sit outside the core vulnerability lookup. Licence scanning reads deps.dev data and can compare against an SPDX allow list. The README gives both forms: ```bash osv-scanner --licenses path/to/repository osv-scanner --licenses="MIT,Apache-2.0" path/to/directory ``` Guided remediation is the more interesting one and the more dangerous. The README marks it experimental and carries a warning that the fix command can be risky when run on untrusted projects. It recommends package version upgrades based on dependency depth, minimum severity, fix strategy and return on investment. That is a genuine differentiator against scanners that only report, but the warning is not boilerplate: a tool that edits dependency manifests on your behalf is executing logic derived from a project you may not have vetted. Treat it as an interactive aid on a branch, not as an unattended CI step. The other honest limitation is coverage. The README lists the ecosystems and lockfile types it supports and does not claim universality. If your build uses a package manager absent from that list, OSV-Scanner will not see those dependencies, and a clean scan means nothing for them. Container scanning is narrower still, limited to Alpine, Debian and Ubuntu for OS packages. The README is also silent on rollback behaviour for the fix command, so plan on version control as your undo. ## OSV-Scanner compared with Trivy, Snyk and npm audit The closest structural alternative is Trivy, which also scans filesystems, repositories and container images from a single binary. The difference is the advisory source and the licence model: OSV-Scanner reads OSV.dev and is Apache-2.0, while Trivy maintains its own vulnerability database pipeline. If your organisation already standardises on Trivy's database or its Kubernetes integrations, switching buys you the OSV format and Google's maintenance, not a new class of finding. Against Snyk the split is commercial. Snyk sells a platform with dashboards, policy and support; OSV-Scanner is a CLI you run yourself. Teams that need an auditor-facing contract will not replace that with an Apache-2.0 binary, and teams that resent per-contributor pricing will not miss it. npm audit is the narrowest comparison. It only covers the npm ecosystem and only within a Node project, and it is invoked through npm. OSV-Scanner covers npm as one of many ecosystems and runs against a directory regardless of what tooling produced the lockfile. If you have a polyglot repository, running npm audit, pip audit and a Maven plugin separately is exactly the fragmentation OSV-Scanner exists to remove. Against Dependabot the difference is direction: Dependabot opens pull requests continuously from GitHub, while OSV-Scanner is something you invoke, on a schedule or in a pipeline, and it also scans container images and reports licences. ## Maintenance, licence terms and the upgrade cost you should budget for The repository is not archived, and the last push was on 2026-09-20. Releases are frequent: v2.6.0 on 2026-09-14, v2.5.1 on 2026-08-17 and v2.5.0 on 2026-08-07. That cadence is a cost as well as a benefit. The README itself notes that the instructions describe the latest V2 beta and points V1 users at a separate repository and documentation site, so a v1 to v2 migration is a real piece of work and the two versions are documented in different places. The project is Apache-2.0, which permits commercial and internal use and modification, with the usual patent grant and notice requirements. That is a statement about the licence text in the repository, not legal advice; if you redistribute the binary or embed it in a product, have your own counsel read the file. The bundled data has its own story: OSV.dev advisories come from upstream sources such as GitHub Security Advisories and Ubuntu security notices, and licence scanning reads deps.dev data, so the terms attached to those datasets are separate from the scanner's licence. Upgrade cost is mostly dependency churn. The Dockerfile pins base images by digest and go.mod pins osv-scalibr to a pseudo-version, so a bump can change which extractors exist. Read the CHANGELOG before moving versions in a pipeline that gates merges on exit codes. ## Conclusion Adopt OSV-Scanner if your dependencies are covered by the lockfile types listed in the supported-languages page and you want a single Go binary that can run in CI, in a container, or fully offline. Do not adopt it as your only control if you rely on a vendor support contract, if you need a package manager outside the documented list, or if you expect the fix command to be safe on code you do not trust. Before rolling it out, run the scanner against one repository and confirm the exit code your pipeline sees, then check the supported-languages-and-lockfiles page for every ecosystem you actually ship. ## FAQ ### What is OSV-Scanner? It is a vulnerability scanner written in Go that acts as the officially supported frontend to the OSV.dev database. The README describes it as a CLI interface to OSV-Scalibr that connects a project's list of dependencies with the vulnerabilities affecting them. ### How do I install OSV-Scanner? The README points to the installation page of the documentation and the GitHub releases page, and says the recommended method is a prebuilt binary for your platform. It also gives go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest for building from source. ### How do I use OSV-Scanner? The README's first example is osv-scanner scan source -r /path/to/your/dir, which recursively scans a directory for supported package files and reports vulnerabilities. Container images are scanned with osv-scanner scan image my-image-name:tag. ### How does OSV-Scanner compare with Trivy, Snyk or npm audit? OSV-Scanner reads OSV.dev advisories and is Apache-2.0, while Trivy maintains its own database pipeline and Snyk is a commercial platform. npm audit covers only the npm ecosystem, whereas OSV-Scanner covers npm as one of many supported ecosystems. ### How do I install OSV-Scanner on Ubuntu? The README does not give a distribution-specific command. It directs readers to the installation section of the documentation and the GitHub releases page, and says the recommended method is a prebuilt binary for your platform, with go install as the build-from-source option. ## Sources - [google/osv-scanner on GitHub](https://github.com/google/osv-scanner) - [License: Apache-2.0](https://github.com/google/osv-scanner/blob/main/LICENSE) - [Project website](https://google.github.io/osv-scanner/) - [README](https://github.com/google/osv-scanner/blob/main/README.md) - [Releases](https://github.com/google/osv-scanner/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-osv-scanner