Use layers, not one database. Start with ecosystem and aggregated open source advisories for package matching, add CVE based data for products and operating system components, then add an exploitation list such as CISA's KEV catalog for ranking. Record which source produced each finding.
Each source answers a different question
| Layer | Example | Answers | Gap |
|---|---|---|---|
| Ecosystem advisories | Registry and language advisory databases | Is this package version affected? | Only that ecosystem |
| Aggregated open source data | OSV | Same, across many ecosystems in a common format | Depends on upstream sources |
| CVE records | CVE program, NVD | Broad coverage including non-package products | Naming can be loose for packages |
| Exploitation evidence | KEV | Is it being exploited? | Small by design |
| Supplier statements | VEX | Is it affected in this product? | Only what suppliers publish |
What aggregation looks like
OSV states that it collects vulnerabilities from databases including the GitHub Advisory Database, the PyPI advisory database, the Go vulnerability database, RustSec, the OpenSSF malicious packages data and others, and that it also converts Debian security advisories, Alpine SecDB and NVD CVEs for open source software. One schema covers all of it. Its aliases field links IDs for the same issue across databases.
KEV is about prioritization, not coverage
CISA describes KEV as a list of vulnerabilities with reliable evidence of active exploitation. An entry also needs a CVE ID and a clear remediation step. It will not find new matches. It tells you which of your matches deserve urgency.
How to choose
- List the ecosystems and platforms in your supplier SBOMs.
- For each, identify the authoritative advisory source.
- Pick an aggregator to cover the long tail.
- Add CVE data for operating system packages and non-package software.
- Add the exploitation list.
- Test with a sample file where you already know the answers, and check what each layer found and missed.
- Store the source on each finding.
Watch for lag
Databases update at different speeds. If a source is slower for your stack, a gap appears between disclosure and your finding. Measure the gap using a few past advisories, and layer another source if it is too wide.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new disclosure is tied to the components it affects, and think about which source would have reported it first.
Where Safeguard fits
Safeguard provides zero-day discovery and SBOM and dependency scanning. Run a free scan to see current findings for your project.
Quick check
Is one database enough for npm and Python and Go?
An aggregator can cover them in one schema, but check lag and coverage with a known sample.
Does KEV find vulnerabilities in my SBOM?
No. It ranks findings you already matched.
Sources
- OSV data sources: aggregated databases and converted feeds.
- OSV schema: aliases and package scoping.
- CISA KEV catalog: inclusion criteria.
Last reviewed: 19 October 2026.
