OSV.dev publishes a list of covered ecosystems, including npm, PyPI, Maven, NuGet, Go, crates.io, RubyGems, Packagist, GitHub Actions and several Linux distributions. Compare it with your stack. If a language or package manager you use is missing, a scanner built on OSV data will have a blind spot there.
Why start with the data
You can compare scanner features for weeks. The question that comes first is simpler: does the underlying data cover what you actually run? A beautiful interface cannot report an advisory that does not exist in its source.
What the published list says
The OSV data sources page lists the ecosystems covered between the data served directly and the data converted from other formats. It includes AlmaLinux, Alpine, Android, Bitnami, crates.io, Curl, Debian GNU/Linux, Git including C and C++, GitHub Actions, Go, Haskell, Hex, Julia, the Linux kernel, Maven, npm, NuGet, opam, OSS-Fuzz, Packagist, Pub, PyPI, Python, R, Rocky Linux, Root, RubyGems, SwiftURL and Ubuntu.
The page presents this as an ongoing project, so the list changes. Check the live page when you do this exercise.
Step by step
- Write down every package manager and language in your estate. Include build tooling, CI actions and base image distributions, not just application code.
- Open the OSV data sources page and compare line by line.
- Mark each of your ecosystems as covered, partly covered or not listed.
- For anything not listed, find out whether your scanner has another data source for it.
- Record the result in your evaluation notes.
| Your stack item | Typical check |
|---|---|
| Application languages | Listed ecosystem for its main registry |
| CI actions | GitHub Actions ecosystem |
| Base images | Distribution entries such as Debian or Alpine |
| C and C++ libraries | Git based entries, with care |
| Internal packages | Not in public data, see below |
Where coverage is thinner than it looks
Listing an ecosystem does not mean every package in it has advisories. It means records exist in that format. Small or niche packages may have no entries simply because nobody has reported anything, which is not the same as being safe.
Internal packages never appear in public databases at all. Your scanner must treat them as unknown, and your policy should say what happens then. Our post on scanner support for private registries goes deeper.
C and C++ deserve a separate look
Dependencies copied into a source tree have no registry. The OSV page notes Git based coverage including C and C++, but matching vendored code to an advisory is harder than matching a package name. Test it with a known case before you rely on it.
Turn the result into a requirement
Your evaluation should say which ecosystems must be covered, which are nice to have and what evidence you will accept, for example a test repository with a known vulnerable version. Safeguard's SBOM and dependency scanning is another candidate to run in that test, and the free scan at https://gold.safeguard.sh/scan lets you try a repository without setup.
Try it yourself
Open the inventory demo and look at how components from different ecosystems appear together. Note whether each component carries an ecosystem label.
Click through it at your own pace, or open it full screen.
Quick check
If my ecosystem is listed, am I covered?
Partly. The format exists for it, but individual packages may still have no records. Test with a known vulnerable version.
What if my language is not listed?
Ask the scanner project which other data source it uses for it, or plan another control for that part of the estate.
Sources
- OSV.dev, Data sources and covered ecosystems
Last reviewed: 19 October 2026.
