When the NVD lags: vulnerability matching beyond one database

For two decades, "check the NVD" was the whole playbook. A CVE got published, NVD analysts enriched it with severity scores and affected-product identifiers, and every scanner downstream keyed its matching on that enrichment. One database, one habit, one point of failure.

That habit broke in early 2024, when the NVD's enrichment pipeline slowed dramatically and a backlog of unenriched CVEs piled up — vulnerabilities that existed, were public, and were exploitable, but carried none of the metadata scanners key on. The program has recovered ground since, and the 2025 funding scare around the CVE program itself was averted, but the lesson stands: a vulnerability pipeline with a single upstream is a pipeline with an outage mode.

What "unenriched" does to your scanner

A CVE without affected-product identifiers is invisible to CPE-based matching — the string your scanner greps for was never written. The vulnerability is real; your report simply doesn't contain it. This is the worst kind of failure, because it looks exactly like being secure.

The multi-source model

The practical answer is to stop treating any single database as ground truth and reconcile several:

1. The NVD, still the richest source for platform and commercial software, and the home of CVSS scoring.
2. Ecosystem advisory databases — OSV and the GitHub Advisory Database key vulnerabilities directly on package ecosystems and versions. For open-source dependencies they are routinely faster than NVD enrichment, and they match on PURL-style identity rather than CPE strings.
3. CISA KEV for the subset that is being actively exploited right now — small, curated, and the strongest single prioritization signal that exists.
4. EPSS for the probability a CVE will be exploited in the near future, refreshed daily.

Each source has blind spots. Ecosystem databases are thin on firmware and commercial products; the NVD is slow on npm and PyPI; KEV is deliberately tiny. Reconciled, they cover for each other — which is exactly how SBOMVault's matching pipeline is built. When one upstream degrades (and they do — we have watched enrichment feeds return errors for an afternoon and recover), matching continues on the others and the gap fills in when the source does.

What to ask of your tooling

If you run your own pipeline, three questions determine whether you inherit the single-source failure mode:

• Does matching survive one database being down or behind?
• Are ecosystem packages matched on package identity, or only on CPE?
• When sources disagree on severity, is the disagreement visible, or silently resolved?

The NVD backlog was a warning shot heard clearly by everyone who was matching on one database. The durable fix isn't a different single source — it is not having one.