Dependency scanning built on better version data
OSV-Scanner connects the packages a project actually uses with advisories in OSV.dev. That sounds like every software composition analysis tool, but the database model matters. OSV records affected ranges in the version scheme used by each package ecosystem and draws advisories from sources such as GitHub, RustSec, and Linux distribution feeds. The scanner can therefore reason about a Go module, npm package, or Ubuntu package without forcing all of them through one generic version format.
The command can recursively inspect a source directory, read supported lockfiles and software bills of materials, detect vendored C and C++ code, or examine a container image. Coverage spans more than 11 language ecosystems and over 19 lockfile types. Version 2.5.0 moved scanning, filtering, and matching through Google's OSV-Scalibr library, adding more extractors and an experimental route to further Scalibr plugins. This is a real scanner, not merely a loop that submits names to an API.
For a developer, the basic experience is excellent. Download a signed release binary or install with Go, point osv-scanner scan source -r at a repository, and get a useful list of affected packages and advisories. Apache 2.0 licensing makes the tool easy to place in internal and commercial pipelines.
Results can be more actionable than a CVE list
A large vulnerability list is cheap to produce and expensive to use. OSV-Scanner offers call analysis for some ecosystems to determine whether vulnerable functions are actually reached by the project. That extra signal can lower noise without pretending that unreachable code is always harmless. It also supports ignore policy and VEX statements, giving security teams a reviewable way to record why a finding does not apply.
Guided remediation goes further by calculating upgrade suggestions using dependency depth, severity, fix strategy, and expected value. Current write support is narrow: npm lockfiles and manifests plus Maven pom.xml files. Interactive and headless modes are available. This can save time where transitive constraints make a seemingly simple upgrade awkward.
The correct word for this feature is experimental. The README warns that fixing can invoke package managers, execute project scripts, or follow registries named by the project. An open issue makes the risk concrete: the interactive npm relock path reportedly runs npm install --package-lock-only without the --ignore-scripts protection used by the non-interactive path. Do not run an interactive write against an untrusted pull request or arbitrary downloaded repository. Review suggestions, use a disposable environment, and let the normal test suite judge the resulting lockfile.
Coverage has boundaries worth testing
Source scanning is broad but not universal. A team should compare every repository's manifests and lockfiles with the published support table, then inspect verbose or structured output to confirm discovery. A zero-finding run is meaningful only when the intended packages were extracted. Local Maven package resolution, platform-specific RubyGems in CycloneDX, and unusual Python requirement names all appear in current or recently fixed reports, illustrating how small parser details affect the result.
Container scanning is similarly specific. The README documents Alpine, Debian, and Ubuntu operating-system packages, with Go, Java, Node, and Python artifacts inside images. OSV-Scalibr's plugin migration is expanding that surface, and version 2.5.0 added ecosystem mappings for several Linux distributions. Experimental plugins should not be counted as guaranteed coverage until tested against representative images.
License scanning uses deps.dev metadata and can enforce an SPDX allowlist. It is convenient beside the vulnerability scan, but it is not yet the feature to trust blindly as a release gate. A current issue reports a full panic when an Alpine package has an empty license field. Another report concerns license scans failing when deps.dev is unavailable. Keep legal review and an SBOM in the process rather than treating this flag as the sole record.
Privacy and CI require explicit choices
Normal scans query OSV.dev with package names, versions, ecosystems, and sometimes file hashes. Dependency resolution, container metadata, licenses, and deprecation checks may use deps.dev; native resolution can contact Maven Central, npm, or PyPI. The README says source code itself is not transmitted, but dependency metadata can still be sensitive in a private product.
Offline mode downloads local OSV databases and then scans without network access. This is the right choice for isolated builds and stricter organizations, provided someone refreshes the databases often enough. Cache the scanner and advisory data deliberately, verify update failure behavior, and record the database age in CI artifacts. Offline does not automatically reproduce every online enrichment supplied by deps.dev or registries.
For CI, pin the binary, choose JSON or SARIF where downstream systems need stable parsing, and establish policy outside a developer's terminal. Decide whether all findings fail, whether severity matters, how ignores expire, and who reviews VEX claims. The scanner provides evidence; it does not define the organization's risk threshold.
A healthy project with visible growing pains
Version 2.5.0 was released August 7, 2026, and the repository was pushed again that day. Issues and pull requests were also active on August 7. GitHub's count of 120 includes both, and the queue shows extractor fixes, ecosystem additions, dependency maintenance, and longer-term version 3 work alongside bug reports. That is healthy engineering activity, not a quiet backlog.
Documentation is a major asset. Separate pages cover installation, supported inputs, source and image usage, output formats, configuration, offline databases, license checks, and guided remediation. The privacy section plainly lists each outside service and the data sent. Supply-chain posture also includes an OpenSSF Scorecard badge and SLSA level 3 release claim, though every adopter should still verify artifacts according to its own policy.
OSV-Scanner is an easy recommendation for dependency vulnerability discovery. It combines an open advisory source, good ecosystem semantics, useful CI output, and a low-friction CLI. The qualification is scope: validate extraction, keep databases fresh, and separate dependable scanning from experimental automated changes. Used that way, it is a strong default rather than a promise that one green command has secured the whole repository.