Your asset inventory doesn't wait for NVD

On April 15, NIST moved the NVD to risk-based enrichment — only KEV-listed, federal, and EO 14028 "critical software" CVEs get the full pass, with everything else tagged Not Scheduled or Deferred. For anyone matching asset inventories against CVE configurations, that's a real change in what arrives machine-ready.

We've been building for that change since February 2024. This post is a short brief on what's in the Vulners configuration layer today — the data you can use to search CVEs by a CPE string or a vendor/product/version triplet, and the products that ride on top of it.

Coverage, in numbers

Across the 103,434 CVEs we've tracked since the NVD backlog began on February 12, 2024, 95,208 — 92.05% — have at least one searchable configuration once NVD, CNA, CISA Vulnrichment, and Vulners' own layer are combined. NVD alone covers ~67%. The 25-point gap is the share of CVEs you can query by product and version in Vulners that you can't find by asking NVD alone.

The full overlap looks like this:

Searchable CPE configurations by source, 2024-02-12 to 2026-04-18. Generated 2026-04-19.

A few things the chart surfaces. 20,477 CVEs have a searchable configuration only in Vulners' own data — no NVD, no CNA, no Vulnrichment equivalent. 27,377 are covered by NVD and Vulners together, with neither source providing the match on its own. 18,544 sit only in NVD. And just 27 CVEs have all four sources filled in — a reminder that the layers are complementary, not redundant. Remove any one of them and the coverage line drops.

The gap has been there for two years. April 15 made it policy-proof.

Four sources, one searchable layer

Each source lands in a single SCAP-compatible layer, so the same matching logic applies regardless of origin:

• Vulners CPE configurations — our own, drawn from ~40 CNAs and built with per-CNA handlers that normalize each authority's conventions.
• NVD CPE configurations — the canonical NVD-assigned entries, still applied to CVEs that pass the three new priority criteria.
• CNA-provided CPE configurations — drawn from the CPE Applicability containers inside CVE Records. Only a handful of CNAs populate these today — Microsoft is the most visible example — but when a CNA ships configurations in SCAP-compatible form, that data is authoritative and lands straight into the layer.
• CISA Vulnrichment — CISA's project filling CVSS, CWE, and CPE for CVEs that NVD hasn't processed. New CPE additions stopped in December 2024, so Vulnrichment contributes to the historical coverage but is no longer a moving line.

The audit API is the way to put this layer to work.

How to use it

The entry point is audit/software. Two input shapes:

// Full CPE
"cpe": ["cpe:2.3:a:ivanti:connect_secure:22.7:r2.4:*:*:*:*:*:*"]

// vendor/product/version triplet
"software": [{"product": "curl", "version": "7.85"}]

The response comes back with the matched CPE, applicable CVEs, CVSS, EPSS, KEV status, and exploitation signals. Response time is around 0.1s per component. search/cpe does the reverse lookup when you need to clean noisy vendor or product strings before a run — searching "curl" returns haxx:curl as the best match instead of the 300+ hits the raw CPE dictionary yields. The full request/response shape is in the Assessment docs.

Where it shows up

The same configuration layer powers three products:

Assessment — pass an inventory from your CMDB, XDR, or build pipeline; get applicable CVEs back. No network probe, no scanner credentials, no scan window. Fast enough for CI/CD gates and continuous passes over large estates. (Assessment docs.)

Alerts — subscriptions in the same CPE shape. Define "software": ["cpe:2.3:a:google:chrome:..."], and matching new CVEs land as webhook JSON or email on a cron schedule you pick. Filters for severity, tags (RCE, zero-day), and wildExploited cut the noise so only actionable items reach engineers. (Alerts docs.)

Datasets — the full four-source configuration layer ships as part of every Archive API snapshot, refreshed every ~4h from CDN. For anything newer than the last snapshot, the database serves a rolling 25h update window directly. Mirror the corpus into Elasticsearch or a data lake, upsert by id, checkpoint on timestamps.updated. Useful when you want to own the data and run matching inside your own stack. (Datasets docs.)

A note on Linux packages and OSS components

CPE is the right tool for commercial software with a clear vendor/product/version identity. For Linux packages and open-source libraries, native package data is the better fit — a distribution's own naming and versioning rules encode things CPE can't, including backports, epochs, and per-distro security patches.

Don't try to invent a CPE for those. Use:

• audit/linux — pass package lists per distribution (apt, yum, dnf, apk) and get findings per package, with distribution-specific version semantics applied.
• audit/sbom — ingest SPDX or CycloneDX and match against OSV records using PURL and ecosystem identifiers.
• audit/package/{ecosystem} — lockfile-native endpoints for npm, pip, poetry/uv, maven, and golang when you'd rather hand over the package manager's own output than build an SBOM.

Same enrichment comes back from every one of these endpoints — CVSS and EPSS scores, CISA KEV status, the wildExploited flag (aggregated from KEV, AttackerKB, ShadowServer, and CIRCL), linked PoC code and exploit advisories, fix versions, and an AI Score for triage. It is the CVE Fusion record graph doing the work underneath every audit call: 218+ sources normalized and cross-referenced so a CVE, its vendor advisories, its exploits, its patches, and the exploitation signals around it all live inside one record.

Arrive by CPE, Linux package, SBOM, or lockfile — the response shape is identical, the same decision signals land on every finding, and you can follow any reference outward into the rest of the graph without a second lookup. One contract for the CI/CD gate, one place to trace why a component flagged, one data backbone behind all of it.

Closing

The audit API predates the NVD crisis by years — asset-based CVE matching has always been a core Vulners use case. What started in February 2024 is the proprietary configuration layer: our own CPE data, generated to keep coverage moving when NVD stopped shipping on time. April 15 makes that investment structural for everyone else — the share of CVEs arriving Not Scheduled is now a published policy number, not a delay that might close.

The endpoints above are live today. If a product or CNA matters to your workflow and isn't matching the way you expect, send a note — that's how the coverage has grown for two years, and it's the kind of industry problem that gets solved faster with feedback than with announcements.