How can developers use the OSV API and Vulnerability Scanner?

OSV (osv.dev) provides two main ways to bring vulnerability data into your own workflow: the API for programmatic queries, and the Vulnerability Scanner for checking dependencies against known vulnerabilities. Both are listed as entry points on the OSV site, alongside GitHub Workflows and remediation tools that let you wire the data into CI/CD or dependency management. This guide covers what each option does, how to use it, and where it fits.

What OSV gives you to work with

OSV is described as "a distributed vulnerability database for Open Source" using "an open, precise, and distributed approach to producing and consuming vulnerability information." All advisories use the OpenSSF OSV format, which the site says was "developed in collaboration with open source communities" and provides "a human and machine readable data format to describe vulnerabilities in a way that precisely maps to open source package versions or commit hashes."

That precision matters for automation: because records map to specific package versions or commit hashes, a tool can tell you whether your exact dependency version is affected, rather than just flagging a package name.

A sample record from the site shows the structure:

{
  "schema_version": "1.7.4",
  "id": "GHSA-c3g4-w6cv-6v7h",
  "modified": "2022-04-01T13:56:42Z",
  "published": "2022-04-01T13:56:42Z",
  "aliases": ["CVE-2022-27651"],
  "summary": "Non-empty defaul..."
}

Note the aliases field — it links the OSV ID to other identifiers like a CVE, which helps when correlating with other security data sources.

Using the OSV API

The OSV site lists "Use the API" as a primary entry point. The API lets you query the vulnerability database programmatically instead of searching the website by hand.

Input: a package identifier (ecosystem + package name, and typically a version) or a commit hash. Action: send a query to the OSV API. Expected result: matching vulnerability records in OSV format, which you can parse and act on.

This is the right choice when you want to:

• Build vulnerability checks into your own tooling or scripts.
• Query on demand during a build, release, or dependency-update process.
• Feed results into a dashboard or alerting system.

Because OSV records map to precise versions, you can ask "is this specific version affected?" rather than pulling a broad list and filtering yourself.

Using the Vulnerability Scanner

The Vulnerability Scanner is the other listed entry point. Where the API is for building your own integration, the scanner is a ready-made way to check dependencies for known vulnerabilities.

Use it when you want to:

• Scan a project's dependencies without writing API code.
• Get a quick picture of known issues before deciding on deeper integration.

The scanner and the API draw on the same underlying database, so results should be consistent — the difference is convenience versus control.

Fitting OSV into your development flow

The site also lists GitHub Workflows and Remediation Tools as entry points, which points to the intended use case: catching vulnerabilities automatically as part of normal development rather than as a separate manual step.

A practical pattern:

1. In CI/CD — run a scan (via the scanner or an API call) on each build or pull request so new vulnerable dependencies are caught before merge.
2. In dependency management — check dependencies against OSV when adding or upgrading packages.
3. For remediation — use the remediation tooling to move from "this is vulnerable" to "here's the fix."

For example, a team that wants a failing check when a dependency has a known vulnerability would wire an OSV query into their pipeline rather than relying on someone remembering to check the website.

Choosing between the API and the scanner

If you're building a custom pipeline or need precise, version-level answers in your own tooling, start with the API. If you want to check dependencies quickly or add a scan step with minimal effort, start with the scanner.

Coverage to keep in mind

OSV covers a large set of ecosystems, so it's likely to include the packages you depend on. The site lists ecosystems including npm (228,869 vulnerabilities), PyPI (25,190), Go (9,245), Maven (7,044), crates.io (2,739), RubyGems (5,326), NuGet (1,869), Packagist (7,098), Hex (364), and Hackage (33), among many others — plus distribution and OS-level sources like Debian (68,551), Ubuntu (65,628), Alpine (4,608), Red Hat (23,387), and SUSE (23,350).

Check the ecosystems list on the site to confirm your stack is covered before designing an integration around it.

Getting started

1. Go to osv.dev and open the Use the API or Vulnerability Scanner entry point.
2. For the API: identify the ecosystem and package (and version or commit) you want to check, then query and parse the OSV-format response.
3. For the scanner: point it at your project's dependencies and review the reported vulnerabilities.
4. To automate: connect the API or scanner to your CI/CD or GitHub Workflows so checks run on every relevant change.
5. To act on findings: use the remediation tools to resolve flagged vulnerabilities.

The site's Docs and FAQ sections are the place to confirm exact request formats and current scanner behavior, since those details can change.