You can often reuse OSV advisory data, but the terms depend on the source database, not on OSV as a whole. Sources range from CC0 to CC-BY 4.0, CC-BY-SA 4.0, Apache 2.0, MIT and BSD, and some converted data has no stated license. Check the source of each record before you redistribute it. This is not legal advice.
Why one dataset has many licenses
OSV.dev collects advisories from many upstream databases and exports them in a common format. The records keep the character of where they came from. The OSV data documentation lists the license for each source it aggregates.
What the documentation lists
| License | Sources named on the OSV data page |
|---|---|
| CC-BY 4.0 | GitHub Advisory Database, PyPI Advisory Database, Go Vulnerability Database, OSS-Fuzz, Python Software Foundation database, Erlang Ecosystem Foundation CNA |
| CC0 1.0 | Rust Advisory Database, Global Security Database, Haskell Security Advisories, opam |
| CC-BY-SA 4.0 | Ubuntu |
| Apache 2.0 | R Consortium Advisory Database, OpenSSF Malicious Packages, Bitnami Vulnerability Database |
| MIT | Drupal Advisory Database, AlmaLinux |
| BSD | Rocky Linux |
| No license stated | Converted data from Debian, Alpine and NVD CVEs |
Note what this means. CC0 is a public domain dedication. CC-BY needs attribution. CC-BY-SA needs attribution and share-alike for adaptations. Apache 2.0, MIT and BSD have their own notice requirements. "No license stated" is not the same as "free to use"; it means the page does not tell you, so go to the original publisher.
When this matters
- You show advisory text in a product. A dashboard that quotes advisory descriptions is reusing text. Attribution may be needed.
- You redistribute a bundle. If you ship a database snapshot to customers or put it in a container image, you are redistributing the content.
- You build a derived dataset. Merged and modified data can trigger share-alike terms for some sources.
- You only query it internally. Internal matching rarely raises the same questions, but keep a note of sources.
A short checklist
- List which ecosystems you use records from.
- For each, find the source database and its license on the OSV data page.
- Decide if you display, redistribute or merely match.
- Store an attribution file for CC-BY sources with the build.
- Treat the Ubuntu share-alike case separately and ask legal counsel.
- For records with no stated license, read the original publisher's terms.
- Re-check when you add an ecosystem.
Related: OSV bulk dumps or API, which to use covers how to fetch the data, and the license check applies to either route. For the license side of code you ship, see our posts on CC-BY attribution.
What to record
Keep a short table in your repository: source, license, link, date you checked. Customers who ask "what data does your tool use, and do you have the right to use it" then get a one-line answer.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning and compliance evidence automation. If you are asked about the origin of the advisory data in any tool, ask for the source list in writing. You can also run a free scan at gold.safeguard.sh/scan.
Quick check
Is OSV data under one license?
No. The OSV data page lists a license per source database, and some converted sources have none stated.
Does CC-BY need attribution?
Yes. CC-BY 4.0 requires credit to the source. CC0 does not.
Is this legal advice?
No. It is a summary of a public page. Ask counsel before you redistribute data.
Sources
- OSV.dev, Data dumps and sources, fetched 19 October 2026.
Last reviewed: 19 October 2026.
