Project Idea: OSV as the solution for the Global Vulnerability Database (for open source) and mitigation for the CVE ecosystem existential risk

[andrewpollock]

This is slightly premature of me to be putting into circulation, but I want an issue ID to add to material I'm creating for collecting feedback...

Related: #162 and #163

Proposed Story

Proposed Story

• OSV is “the (better) CVE, for Open Source Software vulnerabilities”
  • Remove the globally unique identifier gap
  • Draw clear lines as to how it meets the intent of existing compliance regimes
• Free from single-points-of-failure
  • OSV Schema is an OpenSSF project
  • Home databases are fully federated
• OSV.dev
  • Has alternatives
  • Is sufficiently de-risked

The Opportunity for OSV to fill this gap

The Opportunity for OSV to fill this gap

• OSV already exists
  • Highly machine-readable
  • Today, 20+ fully-federated home databases, aggregated by OSV.dev (Google-sponsored)
  • Reference tooling exists (OSV-Scanner, Google-sponsored)
• Open source-scoped CVE Program CNAs parallel-publish in OSV and CVE
  • Requires reducing friction around OSV home database standup
  • Requires reducing friction around home database record management
• Actively learn from CVE Program’s 25 year history
  • Scaling challenges and operational bottlenecks
  • Data quality guardrails
    • https://osv.dev/blog/posts/announcing-data-quality-initiatives/

[oej]

We are going to organise a webinar on this topic in the GVIP group.

[gregkh]

OSV is much more limited in detail than what is available in other formats already (it's a meta-grouping of external reports), so why would you want people to move to OSV instead? Lots of information would be lost if one were to move from reporting in CVE json format to only in OSV json format.

[oej]

OSV is much more limited in detail than what is available in other formats already (it's a meta-grouping of external reports), so why would you want people to move to OSV instead? Lots of information would be lost if one were to move from reporting in CVE json format to only in OSV json format.

Great feedback. Let's see if we can find a time when you can participate :-)

[oej]

Do we have a side by side comparison of CVE json and OSV json to show the difference?

[gregkh]

CVE's schema is here https://github.com/CVEProject/cve-schema

[andrewpollock]

OSV is much more limited in detail than what is available in other formats already (it's a meta-grouping of external reports), so why would you want people to move to OSV instead? Lots of information would be lost if one were to move from reporting in CVE json format to only in OSV json format.

Hey @gregkh, I'm not sure that I'd say this statement is at all correct. Are you referring to https://ossf.github.io/osv-schema/ or something else?

Do we have a side by side comparison of CVE json and OSV json to show the difference?

@oej Yes! Curl is a great example that is parallel-publishing, so compare and contrast

https://curl.se/docs/CVE-2025-0167.json (or https://api.osv.dev/v1/vulns/CURL-CVE-2025-0167)
with
https://cveawg.mitre.org/api/cve/CVE-2025-0167

[gregkh]

OSV is much more limited in detail than what is available in other formats already (it's a meta-grouping of external reports), so why would you want people to move to OSV instead? Lots of information would be lost if one were to move from reporting in CVE json format to only in OSV json format.

Hey @gregkh, I'm not sure that I'd say this statement is at all correct. Are you referring to https://ossf.github.io/osv-schema/ or something else?

That is what I am referring to, at first glance, it looks like there is a lot less information there than in the cve schema. But I would be glad to be proven wrong :)