Wiki · Concept · Last reviewed June 25, 2026

Open Source Vulnerabilities (OSV)

Open Source Vulnerabilities, usually shortened to OSV, is a vulnerability format, database, API, and tooling ecosystem for matching known open source vulnerabilities to exact packages, versions, and commits.

Category: Concept Updated: June 25, 2026 Tags: AI security, open source, OSV, vulnerability management, SBOM, supply chain

Definition

Open Source Vulnerabilities is an OpenSSF vulnerability format and public infrastructure for open source security data. The OSV homepage describes OSV as a distributed vulnerability database for open source, and says its schema is a human- and machine-readable data format that maps vulnerabilities to open source package versions or commit hashes.

OSV is not simply another name for CVE. A CVE record gives a public vulnerability identifier. OSV focuses on practical matching in open source ecosystems: which package, in which ecosystem, at which version or commit, is affected. That is the layer where scanners, lockfiles, SBOMs, and dependency graphs need precision.

For AI systems, OSV matters because many model-serving stacks, agent tools, evaluation harnesses, notebooks, containers, plugins, and retrieval systems depend on ordinary open source packages. When a coding agent adds a package or changes a lockfile, OSV is one of the evidence sources that can help decide whether the dependency is already associated with known vulnerability records.

How It Works

OSV has three main parts. The OSV schema is the JSON format. OSV.dev is reference infrastructure that aggregates, enriches, indexes, and exposes OSV-formatted vulnerability data. OSV-Scanner is the officially supported front end for querying OSV.dev from developer workflows.

The schema contains fields such as an identifier, modified time, aliases, affected packages, ranges, versions, references, and database-specific or ecosystem-specific data. The affected package object uses an ecosystem and name, with optional Package URL support. That ecosystem field matters because the same package name can mean different things in npm, PyPI, Debian, Go, Rust, or another registry.

OSV.dev provides an API for querying an aggregated vulnerability database. Its documentation says command-line tooling can scan SBOMs, language manifests, and container images. The OSV FAQ also notes that the database can be downloaded and that OSV.dev is an aggregator of records from multiple upstream sources, so the most appropriate place to correct a bad record is often the source database.

Agent Context

Agentic software makes package identity a live governance problem. An agent can install dependencies, update manifests, generate container images, introduce transitive packages, or recommend quick fixes that hide dependency drift. OSV helps because it can be checked against the same artifacts agents alter: lockfiles, manifests, SBOMs, container contents, and repository state.

The useful control is not "ask the model whether the package is safe." It is to bind an agent action to a repeatable query: package ecosystem, package name, version, source, manifest path, scanner result, OSV record, and human approval rule. OSV can then feed SSVC, EPSS, VEX, or internal risk decisions.

Governance and Safety

OSV is evidence, not assurance. It does not prove that a package is trustworthy, actively maintained, correctly licensed, reachable in production, or free from undisclosed flaws. It also does not cover every AI-specific issue, such as prompt injection, unsafe tool authority, model-output leakage, or a private vulnerability in a hosted service.

A governance-grade OSV workflow should store the query date, package ecosystem, package name, version, PURL where available, source artifact, scanner version, OSV IDs returned, aliases such as CVE IDs, upstream source links, exception owner, and remediation decision. In an AI Bill of Materials, that record should connect packages to model-serving paths, agent tools, container images, and deployment owners.

Defense Pattern

Source Discipline

Claims about OSV should distinguish the schema, the OSV.dev database and API, OSV-Scanner, and upstream advisory databases. A record shown through OSV.dev may originate elsewhere. If the upstream advisory is authoritative for a fix or affected range, cite that source too.

OSV should not be confused with CVE, CVSS, EPSS, VEX, PURL, SBOM, GUAC, or a package manager audit command. These tools can reinforce each other, but each answers a different question.

Spiralist Reading

Spiralism reads OSV as a repair to naming drift. Modern software does not arrive as one product. It arrives as ecosystems, manifests, ranges, tags, commits, forks, and containers. OSV makes the wound legible at the level where machines actually consume code.

Open Questions

Sources

Return to Wiki