When you correlate an SBOM, the source you correlate against quietly determines what you find. Pick one and you inherit its blind spots. For a programme where a missed vulnerability can mean a missed CRA report, that's a decision worth making deliberately.
Why more than one source
Each major database was built for a different purpose, so each is authoritative for a different slice of the landscape and weaker elsewhere. Coverage overlaps but never completely, and timeliness varies. Correlating against several — then deduplicating and attributing — gives a picture no single feed provides, and one you can defend as thorough.
NVD — the broad baseline
The NIST National Vulnerability Database is the long-standing reference: CVEs enriched with CVSS scores and CPE identifiers, broad across vendors and products. It's the natural baseline. Its well-documented enrichment delays, though, mean recently published CVEs can sit without the metadata correlation depends on — so it can't be your only source, especially for fresh vulnerabilities.
EUVD — the European context
The EU Vulnerability Database, operated by ENISA, aggregates vulnerability information relevant to the EU market and is aligned with the CRA and NIS2. For a manufacturer complying with an EU regulation, it's a first-class source: it reflects the authority whose framework you're working within, and it's designed to fill gaps left when other feeds lag. Correlating against it is part of doing CRA correlation properly, not an optional extra.
OSV — the open-source depth
Open Source Vulnerabilities is package-ecosystem-native, keyed to purls and precise version ranges per ecosystem (npm, PyPI, Go, and so on). Since most of a modern SBOM is open-source dependencies, OSV typically gives the most accurate matching for the bulk of your components — the place where fuzzy, CPE-based matching produces the most false positives.
And KEV, separately
CISA KEV belongs in the same pipeline but answers a different question. NVD, EUVD and OSV tell you what exists and what it affects; KEV tells you what's being exploited in the wild. It's the trigger source, not a correlation source — covered in what counts as actively exploited.
Combining them without double-counting
The same underlying flaw appears across feeds under different identifiers. The goal isn't four copies of every finding — it's one finding that remembers which sources flagged it, matched on precise identity (purl/CPE) with correct version-range logic, and timestamped to the data snapshot. That deduplicated, attributed matched set is what the rest of the CRA pipeline runs on; the mechanics are in the correlation pillar.
Frequently asked
What is the EU Vulnerability Database (EUVD)?
The EUVD is the European Union’s vulnerability database, operated by ENISA. It aggregates vulnerability information relevant to the EU market and supports the CRA and NIS2 frameworks. It became a first-class source manufacturers can correlate against alongside the NVD and OSV.
Why not just use the NVD?
The NVD is broad but has experienced enrichment delays, and it does not cover open-source package ecosystems as precisely as OSV or carry EU-specific context like the EUVD. Relying on it alone leaves timing and coverage gaps.
How do these relate to CISA KEV?
NVD, EUVD and OSV tell you which vulnerabilities exist and affect which components. CISA KEV is a different kind of source — it records which vulnerabilities are being actively exploited. You use the first three for correlation and KEV for the reporting trigger.