OSV-Scanner turns lockfiles into advisory matches
OSV-Scanner reads dependency evidence and asks whether known advisories apply to the named versions. It recognizes source trees, supported lockfiles, Linux packages, and container layers. Underneath, OSV-Scalibr handles inventory and extraction while the OSV database supplies version ranges from public advisory sources. That separation is useful: the scanner is inspectable, the advisory format is machine readable, and teams are not tied to a closed vendor feed.
The tool covers more than a typical package audit command. Its README names C and C++, Dart, Elixir, Go, Java, JavaScript, PHP, Python, R, Ruby, and Rust among supported languages. The detailed matrix lists more than 19 lockfile types across more than 11 ecosystems. Coverage still needs checking for the exact file your build produces. A language name in the headline does not guarantee every package manager or vendor format.
What happened when we ran it
Our sandbox installed 474 Go packages in 88 seconds. The build succeeded in 97 seconds, and the Go test step finished in 199 seconds with 35 passed and 0 failed of 35. The unprivileged container had 3 CPUs and 8 GB of RAM, and we tested commit 3ae687b. No failed command or skipped measured test needs explaining for this run.
The repository was modest beside the other projects in this group: 792 files, about 71,723 lines of source, and a 26.6 MB checkout. Our scan found 19 CI workflow files and a Dockerfile, but no tests directory. Go tests can live beside package code, so the absence of a top-level tests folder is consistent with the 35 passing results rather than evidence that tests do not exist.
The source path is slower than downloading a release binary. The README recommends the prebuilt artifact and offers go install as the alternative. Our combined 384 seconds for install, build, and tests is acceptable for contribution or a pinned CI builder, but users who only need scans should avoid paying that compile cost on every job. Cache the binary or use a verified release artifact.
Online scans disclose dependency metadata
The privacy section is unusually direct. OSV.dev receives package names, versions, ecosystems, and file hashes for vulnerability and vendored-code checks. Deps.dev may resolve graphs, provide container metadata, return license information, and flag deprecated packages. Native resolution can contact Maven Central, npm, or PyPI. The README says source code is not sent, but a dependency inventory can still be sensitive in some organizations.
Offline mode removes those requests after the databases have been downloaded. That shifts responsibility to the operator: database freshness, distribution, storage, and failure handling must become part of the scan job. An old local database can produce a clean report while missing a recent advisory. For disconnected networks, that trade is reasonable, provided the database update timestamp is recorded with every result.
Container support has a defined matrix
Image scanning is layer aware and checks operating-system packages for Alpine, Debian, and Ubuntu. The README's application-artifact table names Go, Java, Node, and Python. That is useful coverage for common service images, though it is narrower than the source-directory language list. An unsupported artifact inside a supported Linux base should not be assumed scanned simply because the command exits successfully.
Call analysis can reduce noise by checking whether a vulnerable function is used in supported projects. That is a prioritization aid, not proof that an advisory is harmless. Dynamic calls, build tags, generated code, and runtime loading can complicate reachability. Keep the original vulnerability match available beside any filtered result so a reviewer can see what the analysis excluded.
Guided fixes deserve a stricter sandbox than scans
The experimental fix command suggests upgrades using dependency depth, severity, strategy, and other criteria. Current documented remediation covers npm package-lock and package.json files plus Maven pom.xml. That is far narrower than the scan matrix, and the README labels the feature experimental. A report can therefore identify a problem in many ecosystems without being able to rewrite it.
More important, Google warns that remediation on an untrusted project may execute package-manager scripts or follow external registries declared by that project. A read-only scan and a fix run have different security boundaries. Run fixes only after reviewing the repository, disable unnecessary credentials, inspect the proposed diff, and execute the project's own tests before merging any dependency change.
v2.5.1 is active, with one Go warning
Release v2.5.1 was published on August 17, 2026. It fixed package namespaces in OSV.dev queries, restored a local database cache environment variable, and repaired a local matching mode. GitHub recorded a push on August 26, with 10,924 stars and 126 combined open issues and pull requests. The queue was active again on August 27.
Open issue 3017 reports a v2.5.0 and v2.5.1 regression involving Go standard-library findings. Another report describes outdated transitive Python resolution and false positives with the default data source. Neither report invalidates the 35 passing repository tests in our sandbox. They do identify cases worth adding to an organization's acceptance corpus before OSV-Scanner becomes a release gate.