↓ Skip to main content
Samarthya
Samarthya
Security

Learning OSV, part 1: what osv.dev is and how to read a record

·4 mins
Technical Security Learning Ssdlc
Table of Contents
Learning OSV - This article is part of a series.
Part 1: This Article
Part 2: Learning OSV, part 2: scanning a project with OSV-Scanner
Part 3: Learning OSV, part 3: guided remediation with osv-scanner fix
Part 4: Learning OSV, part 4: where it fits, and my recommendation
Part 5: Learning OSV, part 5: I scanned my own blog, and the real problem wasn't in the report
A CVE tells you that something is broken. It rarely tells you, in a way a machine can use, which package and which versions. OSV exists to answer exactly that.
Diagram: advisories from GitHub, PyPA, Go, RustSec and malware reports flow into OSV.dev, which publishes a record for GHSA-xvch-5gv4-984h showing npm/minimist affected from 1.0.0 (introduced) to 1.2.6 (fixed), with version 1.2.5 inside the vulnerable range
One record, read as data: the affected range runs from introduced 1.0.0 to fixed 1.2.6, so 1.2.5 is vulnerable and the upgrade target is 1.2.6.

I am learning which free tools can carry real weight in a secure development life cycle. This short series is my proof of concept with OSV: the database, the scanner and its fix command. I run everything for real and keep the output. This part is about the concept and the website.

The problem OSV solves
#

Say your project uses minimist 1.2.5. Is it vulnerable? With a CVE record alone you have to map a product name to your package and read the affected versions from prose. OSV’s own FAQ says the older way of doing this (CPEs) makes it “difficult to do in an automated way” (OSV FAQ).

OSV fixes this with three pieces:

PieceWhat it is
OSV schemaA JSON format where affected versions are written in the package ecosystem’s own terms
OSV.devA database and API that “aggregates, enriches and indexes” advisories from sources such as GitHub Security Advisories, PyPA and RustSec
OSV-ScannerThe official command-line front end: reads your lockfiles and asks OSV.dev what is affected

The key idea is precision. A record does not say “lodash before 4.17.21 is bad” in a sentence; it says it in data that a scanner can compare with your lockfile.

Navigating osv.dev#

The list (osv.dev/list) has a search box and an ecosystem filter. The ecosystems go well beyond language packages: npm, PyPI, Maven, Go, crates.io and NuGet, but also Debian, Ubuntu, Alpine, Red Hat, GitHub Actions and even VS Code extensions. Each row shows the ID, the packages, a summary, when it was published, and whether a fix exists.

The ID prefix tells you where a record came from. A few you will meet often:

PrefixSource
GHSA-GitHub Security Advisories
PYSEC-Python Packaging Authority
GO-Go vulnerability database
RUSTSEC-Rust advisory database
MAL-Malicious packages, not bugs: code published to steal or attack

That last one surprised me. Scrolling the list on a normal morning shows MAL- records published hours earlier: packages that are malware by design. A scanner that knows about them catches something no CVE ever will.

Reading a record
#

Open a record, for example GHSA-xvch-5gv4-984h, prototype pollution in minimist. The page reads top to bottom:

  1. Aliases: the same issue elsewhere. Here, CVE-2021-44906. This is how you join OSV with CVE-based tools.
  2. Published / Modified: published March 2022, modified as recently as March 2026. Records keep improving.
  3. Severity: 9.8 (Critical) with the CVSS vector.
  4. Details and Database specific: the description, the CWE (CWE-1321), and whether GitHub reviewed it.
  5. References: advisory, fix commits, issues.
  6. Affected packages: the part that matters. For npm / minimist it lists ranges: introduced 1.0.0, fixed 1.2.6; and separately introduced 0, fixed 0.2.4.

So 1.2.5 is affected, 1.2.6 is not, and the upgrade path is one patch version. No reading between the lines.

The JSON Data link shows the raw record. Its fields follow the OSV schema: id, aliases, severity, affected[].ranges[].events (introduced, fixed, last_affected) and references.

The one API call worth knowing
#

Ask OSV.dev directly whether one package version is affected:

curl -s -X POST https://api.osv.dev/v1/query \
  -d '{"package":{"name":"minimist","ecosystem":"npm"},"version":"1.2.5"}'

The answer (trimmed) names the record and its CVE alias:

GHSA-xvch-5gv4-984h  aliases: CVE-2021-44906  Prototype Pollution in minimist

GET https://api.osv.dev/v1/vulns/<ID> returns one full record. That is enough to script small checks, but for a whole project the scanner in part 2 does the work.

What I took from this part
#

  • OSV answers which package, which versions, in data, which is what automation needs.
  • The ID prefix tells you the source; MAL- means malware, a class of risk CVEs do not cover.
  • On a record, go straight to Affected packages and the fixed event: that is your upgrade target.
  • Aliases connect OSV to the CVE world.

References
#

Next: part 2, scanning a project.

Author
Samarthya
Engineer, learner, tinkerer. This is my trophy shelf of everyday work and leisure.
Learning OSV - This article is part of a series.
Part 1: This Article
Part 2: Learning OSV, part 2: scanning a project with OSV-Scanner
Part 3: Learning OSV, part 3: guided remediation with osv-scanner fix
Part 4: Learning OSV, part 4: where it fits, and my recommendation
Part 5: Learning OSV, part 5: I scanned my own blog, and the real problem wasn't in the report

Related

SSDLC when exploits are cheap: a working concept

SSDLC when exploits are cheap: a working concept

·16 mins
Technical Ssdlc Vision Security Sast Devops Ai Llm
A fire inspection once a year works when fires are rare. When sparks are falling every day, you need smoke detectors in every room, a sprinkler that fixes the small ones by itself, and a person who decides what to do about the big ones. That is what a secure development life cycle has to become. These are my notes for a question I keep coming back to: how do you keep shipping software when new vulnerabilities arrive faster than you can fix them, and attackers can use an LLM to turn a CVE description into a working exploit? There is no single standard answer. What follows is the concept I would build, with the evidence behind each choice and the parts where I am still unsure.
From finding to fix: Black Duck pull requests on GitHub Enterprise Server

From finding to fix: Black Duck pull requests on GitHub Enterprise Server

·10 mins
Technical Security Sast Github Devops Ci
A vulnerability report that nobody reads is a smoke alarm with no battery. The goal is not more findings. The goal is a pull request that a developer can review and merge before lunch. Why this post # SentinelOne’s overview of GitHub vulnerability management describes the job as “discovering, triaging, and remediating security vulnerabilities in GitHub repositories, dependencies, and workflows”. It lists the usual native tools: Dependabot, code scanning, secret scanning and security advisories. It also admits the gaps: no asset inventory or risk scoring, and dependencies that Dependabot cannot track.
Security standards, plainly, part 4: CISA KEV and BOD 26-04

Security standards, plainly, part 4: CISA KEV and BOD 26-04

·6 mins
Technical Ssdlc Security Devops Sdlc
A hospital emergency room does not treat patients in the order they arrive, or by how loudly they shout. A triage nurse asks a few quick questions and sends the bleeding patient in first. CISA’s KEV catalog and directive BOD 26-04 are triage for vulnerabilities. The first three parts of this series, SSDF, SAMM and SLSA, share one gap: none of them says how fast a vulnerability must be fixed. This part is about the clock.