The 28 Day Blind Spot, Part 1: Why NVD-Based Vulnerability Pipelines Are Structurally Late

A critical severity code execution vulnerability with public exploit code sat outside most security remediation pipelines for 28 days. This is due to systemically flawed designs of pipelines that overly rely on NVD. As time-to-exploitation approaches zero, a month-long delay isn’t good enough, so Specular built an alternative. This 2-part series sets out the problem, the background, and Specular’s extensible, multi-source, low-cost pipeline to surface vulnerabilities weeks before CISA KEV and begin responding to new vulnerabilities the next day.

In an era of rapid exploitation of new vulnerabilities, knowing what to respond to and when to start is key. But the tools built to kickstart that response pipeline have a central flaw: over-reliance on the National Vulnerability Database (NVD) as a sole source of truth. In part 1 of this series, we’re going to explore why NVD-based vulnerability pipelines are flawed and what the alternatives are, and next week we’ll show you the pipeline Specular built to catch critical vulnerabilities weeks earlier.
‍

The anatomy of tracking a new vulnerability 

First, we need to establish some other key players:

• Vulnerability researcher: The one finding and reporting a new vulnerability in some software, hardware or other product.
• cve.org: The definitive public record of known vulnerabilities.
• MITRE: The non-profit chiefly responsible for cve.org. Also runs other community efforts such as MITRE ATT&CK.
• CVE Numbering Authorities (CNAs): Authorities authorized by MITRE/roots to publish CVE IDs. Could be vendors, security organizations, open source contributors or others (full list).
• Authorized Data Publishers (ADPs): Publishers who can enrich further information into CNA CVE entries.
• NIST: The US federal agency responsible for the NVD.
• CISA: The US federal agency responsible for the separate Known Exploited Vulnerabilities (KEV) (the catalog of KEVs actually exploited in-the-wild). Also a root-level CNA, owner of the separate Vulnrichment enrichment program, and more.

‍

So then let’s consider the common path of vulnerability discovery:

1. A researcher finds and (hopefully responsibly) discloses a new vulnerability to the vendor or the appropriate CNA.
2. That CNA (often the vendor itself) triages the report and reserves a CVE ID at cve.org, with no public details attached.
3. A vendor advisory is issued acknowledging the issue and usually a patch is provided.
4. Proof-of-concept (PoC) exploit code may be put out by the researchers, sometimes before the CVE is publicly published.
5. The CVE is formally published at cve.org, alongside a description, affected details and more.
6. Downstream publication and enrichment of the CVE in NVD.‍

All that to say: there are a lot of moving parts and players involved in vulnerability discovery and publication, and a vulnerability becomes public (and of interest to attackers) long before it hits NVD. Any pipeline that ingests from NVD alone is waiting at the last link in the chain and inheriting all the latency that comes with it. In that time, exploitation has often already happened.‍

No matter how rigorous your downstream vulnerability program is, it’s starting late. Scanning your codebase for the offending code, reviewing your CMDB entries for the specific version, automated ticketing integrations to kick-fire the remediation workflows, and carefully-considered SLAs for the dev team to respond: all steps that can be individually perfect, but they can’t counteract a delay that happens upstream of them.
‍

Meanwhile, time-to-exploitation is collapsing

Defenders are often lagging behind attackers, as attackers are only continuing to speed up.‍

Zero Day Clock tracks the gap between CVE publication and observed exploitation across thousands of the most common CVEs and notes that the gap is heading towards 0. Google’s Mandiant M-Trends annual report goes further, claiming a time-to-exploitation of -7 days (i.e. exploitation began 7 days before a patch was even available) against specific edge devices.‍

As we detailed in our previous blog, frontier AI models have only accelerated vulnerability discovery and exploit development post-April. Mythos and other subsequent frontier releases (like Fable, OpenAI’s GPT-5.5 Cyber and Astra, alongside more and more capable and un-safeguarded open weight models) increasingly expand the population of people who can discover new vulnerabilities or who can turn a public advisory into working exploit code.
‍

The enrichment struggle and overreliance on CISA KEV

Enrichment is the process of adding additional contextual data, including CVSS scores (the severity rating assigned to a CVE), CWE (another MITRE-defined mapping scheme) and CPEs (the product-matching field a tool relies on to decide whether a given CVE affects a given asset).

‍

Historically, NIST enriched NVD-registered CVEs with CPEs to aid triage of exploitable systems. However, in April 2026, NIST announced a pullback on this coverage, now only enriching CVEs meeting the following criteria:

• CVEs on CISA’s KEV list
• CVEs for specific software used in US federal government
• CVEs for software defined as critical by Executive Order 14028

For anything outside of the federal government or the EO 14028 categories, NVD’s enriched records are now limited by a KEV listing. This means any pipelines waiting on NVD for its severity and product matching are also waiting for in-the-wild exploitation and CISA cataloguing first, which is a dangerous waiting game. Sometimes KEV alone may buy defenders enough time, but it is obviously insufficient for organizations to stake their entire vulnerability triage pipeline on any one control.

Similar CPE enrichment pullback had previously occurred with CISA’s separate Vulnrichment program in 2024. Effectively, the scale of vulnerability discovery and submission means that enrichment can no longer be guaranteed from sources like NVD, with increasing reliance on ADPs and on the CNAs themselves. Defenders now have a completeness problem in addition to the timeliness problem above.
‍

Single-source is insufficient, so what are our other options?

‍We believe a resilient vulnerability pipeline needs to pull from multiple of these sources, not NVD alone. This includes watching multiple sources, such as:

• NVD itself
• CISA KEV
• Open-source aggregators such as OSV
• Various vendor CNAs or CNAs of “Last Resort,” such as Red Hat
• Vulnerability disclosure programs such as Zero Day Initiative (ZDI)
• Tracking of attacker forums, social media, and other sources for emerging proof-of-concept exploit code

Additional sources could also be considered in future, such as EPSS or alternate KEV lists.‍

In part 2 of this series next week, we will show you the specific pipeline Specular built, and describe its time and cost benefits vs. other options.