OSV-Scanner for coding agents

When a coding agent adds or updates a library, OSV-Scanner checks the project’s dependency files for known security vulnerabilities. It compares package names and versions with security advisories published through OSV.dev. These advisories describe known vulnerabilities and the package versions they affect. A dependency file, such as a lockfile, records the specific package versions a project uses.

An agent with shell access can run OSV-Scanner from the command line after changing dependencies, review the findings, and then propose a commit. OSV-Scanner reads local project files and queries OSV.dev. A standard scan needs no credentials and does not change the project. The steps below show how to install the scanner, scan a local checkout, and interpret the output.

Install the scanner

The installation page lists prebuilt binaries and package managers such as Homebrew (brew install osv-scanner). It also documents installation from source with Go, which needs Go 1.26.2 or later. Run this command in a shell that has Go installed:

go install github.com/google/osv-scanner/v2/cmd/osv-scanner@latest

Go downloads and builds OSV-Scanner, then places the executable in the Go binary directory. Make sure that directory is on PATH so your shell and coding agent can find osv-scanner. Check the official repository for the current installation options and requirements.

A normal scan does not require an OSV.dev account. The scanner needs network access to query vulnerability data. The OSV.dev documentation describes the database as an aggregator of open-source vulnerability databases and names OSV-Scanner as the first-party tool that uses its API.

Scan a local project

From the project’s root directory, run:

osv-scanner scan source -r . --format json

Here, scan source selects source-tree scanning. The -r . flag tells the scanner to examine the current directory and its subdirectories. The --format json flag asks it to print a report that other tools can read. The scanner extracts package information from supported project files, then checks the packages and versions against OSV advisories. The usage documentation describes the scan modes, and the output documentation lists available report formats, including JSON and SARIF. With JSON, the report goes to standard output and other messages go to standard error, so the report can be redirected to a file.

This example assumes you have checked out a project locally and that it contains dependency files OSV-Scanner recognizes. OSV-Scanner reads those files and sends vulnerability lookup requests to OSV.dev. For a Maven pom.xml, it also resolves transitive dependencies through the deps.dev API by default, and --no-resolve turns that off. It does not install, upgrade, or remove project dependencies. By default, it also leaves out files that .gitignore ignores. The JSON report gives an agent structured findings to inspect; it does not by itself prove that vulnerable code runs in the project.

OSV-Scanner’s supported lockfiles and manifests include files for package managers such as npm and pip, plus Maven and Go modules. They also include Cargo, RubyGems, and Composer. Check that list before treating a scan with no findings as complete. If OSV-Scanner does not recognize a package manager or a dependency file is missing, the scan will not cover those dependencies.

Give an agent a bounded task

A coding agent can use the scan after it edits a lockfile or adds a dependency. Ask it to run the command from the project root, summarize any reported findings by naming the packages and affected versions. Include the advisory details, then propose next steps without changing dependencies. A concise prompt could be:

Run osv-scanner scan source -r . --format json from the repository root. Summarize any vulnerability findings and identify the affected dependency files. Do not run a fix or edit dependencies; propose a separate remediation for review.

This lets the agent inspect findings without changing project files. The agent still needs permission to run OSV-Scanner, and the command sends network requests to OSV.dev. Keep credentials out of the prompt; the standard scan does not need them.

If the agent wants to try remediation, review the proposed version changes separately. OSV-Scanner documents a fix command for guided remediation, but marks the feature experimental. Its documentation warns that the command can trigger the package manager to run scripts or follow external registries named in the project, so an agent should not run it automatically on an untrusted checkout. Review the command and its changes under version control before accepting them.

Read findings within their limits

OSV-Scanner reports matches against the advisories available through OSV.dev. An advisory match identifies a known affected package version; it does not establish whether the project executes the vulnerable code. OSV-Scanner cannot cover dependencies in package formats it does not recognize. Its results also depend on the advisories in OSV’s data.

The exit code helps an agent read the result. The output documentation lists 0 when the scanner found packages but no known vulnerabilities, and 1 when it found vulnerabilities. Exit code 128 means it found no packages, likely because it picked up no files to scan.

After the agent finishes editing, scan the dependencies recorded in the project. Use the report to identify packages that need investigation, then inspect the relevant advisory and decide whether to upgrade, replace, or otherwise address each dependency. For more on OSV-Scanner’s inputs and options, consult its usage guide and the Awesome CLI directory.