Open Source Vulnerability Database: OSV and GHSA

The open source vulnerability database problem is not finding one more feed. It is knowing which package fact to trust when the feeds disagree.

OSV and the GitHub Advisory Database, usually shortened to GHSA, solve a problem that broad CVE catalogs handle poorly: mapping a vulnerability to the exact package and version language developers use. They are related, but they are not duplicates. GHSA is a curated advisory source. OSV is a shared data format, an aggregation service, an API, and a scanner built around ecosystem aware version ranges.

Choosing one and ignoring the other is the wrong decision. Consume both with provenance, reconcile aliases, and test the result against the dependency state you actually run. The useful output is not “three databases matched.” It is “this package in this workload is affected, this version fixes it, and this owner can prove the change.”

What is an open source vulnerability database?

An open source vulnerability database records security issues in libraries, packages, distributions, and source repositories whose code and advisory data can be inspected. The phrase can be confusing. The older Open Source Vulnerability Database, OSVDB, shut down in 2016. The modern OSV project at osv.dev is different. It was created to express affected versions in the native terms of package ecosystems and source commits.

That focus fixes a common matching failure. A developer installs jinja2 from PyPI, not a CPE string. A Go team tracks modules and semantic versions. A Linux distribution may backport a fix without changing the version the way a generic matcher expects. Package name, ecosystem, commit, introduced version, fixed version, and withdrawn status are the facts that make an advisory actionable.

The official OSV data source documentation lists sources such as GHSA, PyPA, Go, RustSec, OSS-Fuzz, Ubuntu, Debian, and Alpine. OSV aggregates them into one schema while retaining source identity. That last part matters. Aggregation should make data easier to consume, not erase who asserted it.

How are OSV and GHSA different?

GHSA begins close to maintainers and repositories. A project can privately coordinate a report, request a CVE, publish affected package ranges, and feed Dependabot from the resulting advisory. GitHub reviewers validate package identity, version ranges, duplicate records, severity, and weakness data for reviewed advisories.

OSV begins with interchange. Its schema can represent ranges from package ecosystems and Git commits without forcing every project through one naming convention. OSV.dev then imports compatible advisory sources, exposes a public API, publishes downloadable data, and powers OSV-Scanner. GHSA is one of the sources OSV consumes, so a GHSA identifier often appears as an OSV record ID with CVE and ecosystem aliases attached.

The practical rule is simple. Use OSV for broad package matching and portable automation. Use GHSA when you need GitHub review state, repository disclosure context, Dependabot behavior, or the GitHub advisory API. Preserve both records when they contribute different claims.

What changed in open source advisory data in 2026?

Volume stopped being a background concern. GitHub reported on June 29, 2026 that its advisory team sustained more than 6,000 advisory decisions per month from March through May. Private vulnerability reports rose from about 550 each week in January to more than 3,000 each week for most of May. Repository advisories climbed from about 650 to more than 5,000 each week. GitHub also said more than 1.7 million repositories had enabled private reporting.

That surge changes how consumers should read status. A reviewed GHSA has passed human validation. An unreviewed record may be useful and timely, but it has not passed the same check. A delayed review is not proof that an issue is false. It is evidence that your ingestion should retain review state and that high impact cases may need direct vendor confirmation.

A second development landed on August 6, 2026. GitHub announced that it had connected the OpenSSF malicious packages feed, expressed in OSV format, to GHSA and Dependabot. The expanded malware advisory pipeline covers eight package ecosystems and draws from more than 15,000 public reports. GitHub found that more than half of new npm reports in the upstream feed were round trips from its own data and had to be discarded. That is the duplicate problem in one number.

How do you query OSV by package and version?

Query the package name exactly as the registry knows it, include the ecosystem, and include the installed version. This command was checked against the current OSV API and returns the advisories that affect Jinja2 2.4.1:

curl -s https://api.osv.dev/v1/query \
  -H 'Content-Type: application/json' \
  -d '{"version":"2.4.1","package":{"name":"jinja2","ecosystem":"PyPI"}}' |
  jq -r '.vulns[] | [.id, (.aliases // [] | join(",")), .modified] | @tsv'

The alias column is not decoration. One returned record can carry a GHSA ID, a CVE ID, a PYSEC ID, and another source identifier. Store them under one internal advisory entity. If each alias becomes a separate ticket, the same package flaw creates four queues and four claims about closure.

For a repository or image, OSV-Scanner version 2 uses explicit subcommands. The current syntax isosv-scanner scan source --recursive . for a source tree andosv-scanner scan image image-name:tag for a container image. Pin the scanner version in automation and capture the advisory data timestamp with the result. A scan you cannot reproduce is weak audit evidence.

How do you query the GitHub Advisory Database?

GitHub's global advisories endpoint accepts CVE ID, GHSA ID, ecosystem, package, severity, advisory type, and time filters. Public records can be queried without authentication. This verified example resolves a CVE to its GHSA record:

curl -sL \
  -H 'Accept: application/vnd.github+json' \
  -H 'X-GitHub-Api-Version: 2026-03-10' \
  'https://api.github.com/advisories?cve_id=CVE-2018-6188' |
  jq -r '.[] | [.ghsa_id, .cve_id, .severity, .published_at] | @tsv'

The GitHub global advisory API documentation notes an important default: requests without other parameters return reviewed advisories and exclude malware. Malware queries require type=malware. If your collector assumes the default means all records, it will silently miss a category that GitHub expanded in 2026.

How should you reconcile OSV and GHSA results?

Build a claim ledger, not a winner take all merge. For each source, store the advisory ID, aliases, package coordinate, affected range, fixed version, withdrawn state, review state, modified time, and source URL. Then select a canonical local entity while preserving every claim that contributed to it.

Deduplicate on strong identifiers first. Shared GHSA and CVE aliases are strong. Package plus ecosystem plus an overlapping range is supporting evidence, not a guaranteed match. Similar prose is the weakest signal. Two unrelated packages can share a name, and one project can publish the same code into several ecosystems.

Withdrawals and corrections must flow through the same path as new records. If an advisory is withdrawn on Wednesday, a ticket opened on Monday needs a state change, not a second ticket. Keep the old claim for audit, mark it superseded, and reevaluate any exception or repair decision that depended on it.

How do you measure advisory data quality?

Count decisions the data can support, not fields that happen to be populated. Package identity, ecosystem, affected range, fixed version, source, and modified time are the core. A severity score without a usable package range cannot tell a developer what to update. A range without provenance cannot survive a dispute.

Track four rates: exact package matches, records with a fixed version, conflicts between sources, and withdrawn records processed within your target time. Keep review state beside each rate. A reviewed GHSA and an imported ecosystem advisory may both be correct, but they carry different validation histories.

Sample the output monthly. Pick ten high priority matches and ten closed matches. Confirm the package coordinate, range evaluation, source revision, owner, and deployed result by hand. Automation that is never sampled can be consistently wrong for months. A small review catches mapping errors before they become policy.

The math explains why this matters. A modest estate with 120 services and 40 resolved dependencies per service contains 4,800 package coordinates. Checking two databases creates 9,600 raw comparisons before aliases and duplicates. If 3 percent require manual reconciliation, that is 288 reviews. At ten minutes each, the data gap costs 48 analyst hours. Better entity resolution buys back a full work week.

What does a useful operating model look like?

1. Resolve dependencies from lockfiles, images, and deployed artifacts, not manifest intent alone.
2. Ingest OSV and GHSA with source timestamps, aliases, ranges, and review or withdrawal state.
3. Create one canonical advisory entity while preserving every source claim and conflict.
4. Join matches to runtime use, reachability, exposure, owner, and existing controls.
5. Route a repair with the fixed version and verify the new package state after deployment.

This is where an open database becomes vulnerability intelligence. The public record supplies possible impact. Your environment supplies actual presence and use. Our guide to vulnerability intelligence beyond a CVE feed shows how to keep those two evidence classes separate until the decision is made.

Artemes applies deep endpoint context with AI driven analysis to the local half of that equation. The source discipline still matters. A model cannot repair provenance that an ingestion pipeline threw away.

Frequently asked questions about open source vulnerability databases

Is OSV the same as the old OSVDB?

No. OSVDB was a separate project that shut down in 2016. OSV.dev is the current Open Source Vulnerabilities project built around package ecosystems, source commits, an open schema, an API, and scanning tools.

Does OSV include GitHub Security Advisories?

Yes. GHSA is one of OSV's upstream sources. Keep the GHSA identifier and review state because those details can still matter in a GitHub based disclosure or Dependabot workflow.

Should a team replace NVD with OSV?

No. OSV is stronger for many package and commit matches. NVD covers a broader product set and supplies other enrichment. Use each for the claims it can support and reconcile by identifier and product identity.

Can OSV or GHSA prove a deployed service is vulnerable?

They can prove that a package version is in a published affected range. You still need deployed artifact, runtime, feature, reachability, and control evidence to make the local risk decision.

The executive takeaway

Add OSV and GHSA to one ingestion path, preserve their identities, and measure how many raw matches collapse into canonical advisories and confirmed deployed exposure. Start with one ecosystem this month. Pin the query syntax, record source timestamps, handle withdrawals, and close only on observed package state. More feeds are not the goal. Fewer unsupported decisions are.