NVD Backlog Explained: Where Your CVE Data Actually Comes From

You open an NVD record for a CVE published last week. No CVSS score. No CWE. No CPE list. Just a description and a status that reads Awaiting Analysis. Meanwhile your scanner has quietly ranked it as unscored, your dashboard has sorted it to the bottom of the page, and nobody on your team will ever see it.

That is not a bug in NVD. It is a predictable consequence of how vulnerability data is actually produced, and once you understand the structure the fix is straightforward.

The CVE Ecosystem Is a Supply Chain, Not a Database

Most teams picture one big vulnerability database that everything reads from. There is no such thing. What exists is a supply chain with four layers, each run by different organisations, funded differently, and operating on different clocks:

1. Assignment. A CVE ID is reserved for a specific flaw.
2. Publication. A record describing that flaw becomes public.
3. Enrichment. Someone adds a CVSS vector, a CWE classification and machine-readable product applicability.
4. Exploitation signal. Someone tells you whether it is being attacked.

NVD occupies exactly one of those layers, and only part of it. Every confusing thing about missing scores follows from that single fact.

Layer 1: Assignment, and What a CNA Actually Does

CVE IDs are assigned by CVE Numbering Authorities, or CNAs. There are well over four hundred of them: Microsoft, Red Hat, GitHub, Google, most large Linux distributions, many national CERTs, and MITRE itself as the CNA of last resort. Each CNA has a defined scope, usually its own products.

The CVE Program that coordinates them is operated by MITRE under contract to the US government, sponsored by CISA. This matters more than it sounds, and we will come back to it.

A CNA does two things: it reserves an identifier, and it publishes a record when the flaw goes public. What it is *not* required to do is score the thing.

Layer 2: Publication, the CVE List and Record Format 5.x

The published record lands in the CVE List. Since the move to CVE Record Format 5.x, that record can carry far more than a text description. A CNA can supply its own CVSS vector, its own CWE mapping, and structured affected-product data directly in the record.

Many CNAs do exactly that. Red Hat, Microsoft and GitHub routinely ship a fully scored record on day one. Many others publish a paragraph of prose and nothing else.

So the practical answer to "is this CVE scored?" is not "check NVD". It is "check whether *anybody* scored it, and by which route".

Layer 3: Enrichment, and Why NVD Fell Behind

The National Vulnerability Database is a NIST service that consumes the CVE List and adds its own analysis on top: a NIST-assigned CVSS vector, CWE classification, and CPE applicability statements that say precisely which product versions are affected.

For two decades this was so reliable that the whole industry hardcoded it as the source of truth. Then in February 2024 NIST publicly announced a slowdown in its analysis pipeline, and a large backlog of unenriched records accumulated. Records began sitting in Awaiting Analysis, and later a Deferred status appeared for older material NIST does not intend to enrich at all.

I am deliberately not quoting a backlog number here, because any figure is stale within a fortnight. Check NIST's own announcements page for the current position. The structural point outlives the number: enrichment is a discretionary, resource-constrained layer, and it is not guaranteed to happen.

Reading a Record That Says Awaiting Analysis

When you hit one of these, the record is not empty. It is just not enriched *by NIST*. Work down this list:

• Did the CNA supply a CVSS vector in the record itself? Frequently yes, and it is often better informed than a third-party score, because the vendor knows its own attack surface.
• Has CISA Vulnrichment added an ADP container? See the next section.
• Is it in the KEV catalog? If so, severity scoring is a secondary question; it is being exploited.
• Does it have an EPSS score? EPSS covers essentially every published CVE regardless of enrichment state.

If all four come back empty, you have a genuinely unassessed vulnerability, which is a reason to look harder, not a reason to file it under low risk.

Layer 4: Exploitation Signal, KEV and EPSS Run on Different Rails

This is the single most useful thing to know, so it gets its own section.

CISA KEV is a catalog of vulnerabilities with confirmed exploitation in the wild. EPSS is a daily-refreshed probability model published by FIRST that estimates the likelihood of exploitation activity in the next 30 days.

Neither of them depends on NVD enrichment. They read from the CVE List and their own data. When NVD stalls, KEV and EPSS keep working exactly as before.

That means the two signals most predictive of real-world harm are precisely the two that survive an upstream failure. If your prioritisation leans on them rather than on CVSS alone, an NVD backlog is an inconvenience instead of a blind spot. We have written separately about how CVSS and EPSS answer genuinely different questions and about what the KEV catalog is and how to use it.

CISA Vulnrichment: Enrichment That Skips NVD Entirely

In response to the slowdown, CISA launched Vulnrichment, operating as an Authorized Data Publisher (ADP). An ADP writes into a separate container inside the CVE record itself, adding CVSS, CWE and SSVC decision points without touching the CNA's own container.

The architectural significance is easy to miss: enrichment is no longer a single-vendor function. A record can now arrive scored by the CNA, or by CISA, or by NIST, or by all three, and your parser needs to handle all four cases rather than reading one field and giving up.

April 2025: The Week the CVE Program Nearly Lapsed

In April 2025 the MITRE contract underpinning the CVE Program came within roughly a day of expiring. CISA executed a contract extension at the last moment, and separately a CVE Foundation was announced as a continuity effort aimed at putting the programme on a more independent footing.

Nothing broke. That is not the lesson. The lesson is that a single-upstream dependency for the identifier scheme underneath your entire vulnerability process is now a documented operational risk rather than a hypothetical one, and it deserves a line in your risk register like any other supplier concentration.

EUVD, OSV and the Rise of Parallel Databases

The response has been a proliferation of parallel publication surfaces:

• EUVD, the EU Vulnerability Database, launched by ENISA in 2025 under the mandate in NIS2 Article 12. Europe now has its own publication surface rather than consuming a US one.
• OSV.dev, which is package-ecosystem-native and keyed by PURL rather than CPE. For anything installed by npm, pip, Go modules or Cargo, OSV usually knows the affected version ranges long before a CPE string exists.
• GitHub Security Advisory database, which feeds Dependabot and is often the fastest source for open-source library flaws.
• Distribution trackers from Debian, Red Hat, SUSE and others, which answer the only question that matters for a patching decision: is *my* backported package fixed?
• Vendor PSIRT advisories, which remain the authoritative word on commercial software.

Source Comparison: What Each Adds, How Late, How It Fails

Designing a Feed That Degrades Gracefully

The rule is simple: never let one upstream own a decision.

Assign each field to a chain of sources rather than a single one:

• Severity: CNA vector, or NVD, or CISA ADP, whichever is present. Record which one you used.
• Exploitation: CISA KEV.
• Likelihood: EPSS.
• Applicability: your own inventory, not somebody else's CPE strings.

That last one deserves emphasis. CPE applicability data is one of the first things to go missing when enrichment stalls, and CPE-only product matching therefore under-reports precisely when you can least afford it. This is why our stack tracking matches on concept tags in addition to vendor CPE data: a CVE affecting your version of a library should still reach you when the official product list has not been written yet.

Then add one alerting rule that most pipelines lack: flag records with no severity from any source, and route them to a human. An unscored CVE is an unknown, and unknowns belong in a queue, not at the bottom of a sorted table.

If you want to see how a record looks once it has been merged across these sources, every CVE we track is browsable in the public CVE screener, and the full lifecycle of a disclosure from report to patch covers the stages this article treats as a supply chain.

The takeaway is one sentence: absence of a CVSS score is not evidence of low severity, and any system that behaves as though it is will hide exactly the vulnerabilities nobody has looked at yet.