Every vulnerability scanner you run, every SBOM you generate, and every security advisory you receive resolves to the same underlying data. A CVE identifier, and a record describing it.
Most engineers use that data daily and have never looked at how it is produced. That is fine until the day a delay, a gap, or a disputed record costs you a patch cycle.
This is how the system actually works, where it breaks, and what to do about the parts that break.
The stakes for getting this right are rising faster than most teams' processes are. a16z's tracking shows CVE volume up roughly 10x from 2025 to 2026 alone, which means the pipeline this article describes, discovery to disclosure to enrichment to your scanner, has to run correctly at ten times the throughput it did two years ago, for every one of the thousands of vulnerabilities that hit your dependency tree. An attacker needs one of them to be exploitable and unpatched. You need the pipeline to surface all of them, correctly, before that's true.
Why this matters operationally: CodeAnt AI maintains a vulnerability database and correlates CVE data continuously against live attack surface, rather than at scan time. Understanding the pipeline below is what makes that correlation trustworthy.
What is a CVE?
CVE stands for Common Vulnerabilities and Exposures. A CVE is a unique public identifier assigned to a specific security vulnerability in a specific product.
The critical thing to understand is what a CVE is not. It is not a severity rating, not a vulnerability database entry, and not a patch. It is an identifier and a short description, and that narrowness is deliberate.
Before CVE existed, two vendors describing the same flaw used different names, and correlating them was manual work. The identifier exists so that everyone in the industry can be certain they are discussing the same defect.
How to read a CVE ID
The format is CVE-YYYY-NNNNN.
CVE is the fixed prefix. YYYY is the year the ID was reserved, which is frequently not the year the vulnerability was disclosed. NNNNN is a sequence number of four or more digits, with no upper bound.
The year field trips people up constantly. An ID reserved in December 2025 and published in March 2026 still carries 2025. Never infer disclosure timing from the identifier.
Who Assigns CVE IDs?
CVE IDs are assigned by CVE Numbering Authorities, usually shortened to CNAs. The programme is coordinated by MITRE, which operates as the primary CNA and as the root of the hierarchy.
There are three practical categories of CNA.
Vendor CNAs assign IDs for vulnerabilities in their own products. Most large software companies operate one, which is why a Microsoft or Oracle vulnerability gets an ID directly from them.
Open-source and project CNAs cover ecosystems rather than a single vendor. Several major package registries and foundations operate in this role.
Researcher and coordinator CNAs assign IDs for vulnerabilities in products whose vendor has no CNA, or where the vendor is unresponsive.
If no CNA covers a product, the request escalates to MITRE or to a CNA of last resort.
Why the assignment path affects you
A vendor CNA controls the timing and the wording of the record for its own products. That is efficient and it also means the description reflects vendor framing.
Records assigned through a researcher or coordinator route are often more technically explicit, because the researcher wrote them. CodeAnt's own disclosures, including CVE-2026-29000 in pac4j-jwt and CVE-2026-28292 in simple-git, went through this route, which is why both writeups carry root-cause detail an average vendor advisory would not.
When you are trying to determine whether a CVE affects your specific configuration, that difference in detail is frequently decisive.
What is the NVD, and How Does It Differ from the CVE List?
The NVD is the National Vulnerability Database, operated by the National Institute of Standards and Technology in the United States.
Here is the distinction that resolves most confusion. The CVE List is the identifier registry. The NVD is an enrichment layer built on top of it. Every CVE record originates in the CVE List. The NVD ingests those records and adds analysis that the CVE List does not contain.
Layer | Contains | Operated by |
|---|---|---|
CVE List | ID, description, references, affected products as stated by the CNA | MITRE and the CNA network |
NVD | Everything above, plus CVSS scores, CWE classification, CPE product identifiers | NIST |
What NVD enrichment adds
Three additions do the work.
CVSS scoring. NVD analysts assign a base score, which is where most of the CVSS numbers you see in tooling originate. Note that a CNA may also publish its own score, and the two can differ.
CWE classification. The Common Weakness Enumeration identifier categorises the underlying defect type, such as improper input validation or a use-after-free. CWE is how you spot a pattern across many CVEs.
CPE identifiers. Common Platform Enumeration is a structured naming scheme for products and versions. CPE is what makes automated matching possible, because it turns a prose statement about affected versions into a machine-comparable range.
CPE is the single most operationally important enrichment. Without it, matching a CVE against your inventory is text parsing.
How a Vulnerability Travels from Discovery to NVD Entry
The pipeline has six stages and delay can occur at any of them.
Stage | What happens |
|---|---|
1. Discovery | A researcher, an internal team, or an attacker finds the defect. Nothing is public. |
2. Disclosure to the vendor | Under coordinated disclosure the finder reports privately and a remediation timeline is agreed. Typical windows run 90 days, though practice varies. |
3. CVE ID reservation | A CNA reserves an identifier. The ID now exists in a reserved state, with no public description. |
4. Publication | The vendor ships a fix and the CVE record is published with a description and references. The vulnerability is now public. |
5. NVD ingestion and analysis | NVD picks up the published record and adds CVSS, CWE, and CPE data. |
6. Downstream distribution | Scanners, SCA tools, and distribution security trackers ingest the enriched record. |
Why enrichment delay matters to your patch cycle
Between stage 4 and stage 5 there is a window in which the vulnerability is fully public and the machine-readable data your tooling depends on does not yet exist.
During that window your scanner may not flag an affected component, because it matches on CPE and no CPE has been assigned.
Meanwhile the vendor advisory is public, the patch is available, and anyone diffing the patch has what they need. How that window gets exploited, and how to measure your own exposure inside it, is covered in more depth in CodeAnt's guide to the patch window.
This is not theoretical. The NVD has experienced significant analysis backlogs, during which large numbers of published CVEs sat without enrichment for extended periods.
It's also compounded by how much faster exploitation follows disclosure than it used to. a16z's data on exploited CVEs shows the share exploited on or before the day of disclosure climbing from under 20% in 2018 to nearly 87% in 2026. The enrichment window this section describes used to be a comfortable head start. It's increasingly the entire margin you get.
The operational consequence is direct. If your vulnerability management process begins when your scanner reports a finding, your process begins after the window has already opened.
Two mitigations are worth building:
Subscribe to vendor advisories for your critical stack directly, rather than waiting for the enriched record to reach your scanner.
Treat the CISA KEV catalog as a parallel high-priority feed, because it is populated on evidence of exploitation rather than on enrichment completion.
How to Read a CVE Record, Field by Field
Take any published record and work through it in this order.
Description. One or two sentences naming the product, the affected component, the weakness type, and the impact. Read it for the attack precondition, which is usually the phrase determining whether you are affected at all.
References. The most valuable field and the most skipped. Vendor advisories give you the fix version. Researcher writeups give you technical detail. A link to a commit or a patch tells you precisely what changed.
CVSS vector string. Do not stop at the number. The vector, for example
AV:N/AC:L/PR:N/UI:N, tells you whether the vulnerability is network-reachable, whether it requires privileges, and whether it requires user interaction. Those four values determine your urgency far better than the aggregate score.CWE. The weakness class. Useful for spotting that the same defect type keeps recurring in one of your dependencies.
CPE configuration. The affected version ranges. Check the boundary conditions carefully, because ranges are frequently expressed as "less than" a fixed version rather than as an enumerated list.
Weaknesses and known exploited status. Check whether the record appears in the CISA KEV catalog, which changes your priority immediately.
Reading the vector string is the fastest triage available
A vector containing AV:N and PR:N and UI:N describes something reachable over the network, requiring no privileges, and requiring no user interaction.
That is the pre-authentication remote profile, and it deserves attention regardless of the aggregate number.
A vector with AV:L requires local access. Same base score range, entirely different urgency for an internet-facing service.
That is the vector string's information collapsed into a sortable list. A finding with the pre-authentication remote profile above and a rising EPSS trend sorts to the top without anyone having to read the vector by hand for every row.
The Limits of CVE Coverage
Four categories of vulnerability routinely never receive an identifier, and knowing them prevents a false sense of completeness.
Vulnerabilities in your own code. CVEs are assigned to publicly distributed products. A flaw in your internal application never gets one, which means CVE-based tooling is structurally blind to first-party defects. That is what code review and SAST are for.
Silently fixed bugs. A maintainer who fixes a security issue as a routine bug fix, without requesting an ID, leaves no trace in any vulnerability database. Your SCA tool will report the dependency as clean.
Cloud and service-side vulnerabilities. A flaw in a hosted service fixed by the provider often receives no CVE, because there is no version for you to upgrade.
Configuration and design weaknesses. An insecure default, an over-permissive grant, or a missing control is not a CVE. It is frequently a larger risk than anything in your CVE list, and it is the failure mode behind bug classes like IDOR, which almost never carries a CVE of its own even though it is one of the most common ways data actually leaves a company.
The honest summary. CVE coverage is excellent for known vulnerabilities in versioned third-party software and non-existent for everything else.
Building a security programme solely on CVE data leaves those four categories entirely unaddressed.
How CVE Data Connects to Your Software Inventory
CVE data is only useful when matched against what you actually run. The matching step is where fidelity is lost.
The chain has three links. Your inventory of components and versions, the CPE identifiers in the CVE record, and the matching logic between them.
Each link fails in a characteristic way.
Inventory failures. Your SBOM lists what your build declared. It does not list statically linked libraries, vendored code, or binaries copied into a container image without a package record. Anything absent from the inventory cannot be matched against any CVE.
This is the gap binary composition analysis exists to close, covered in full in CodeAnt's SBOM guide.
It derives the component list from the artifact rather than from the manifest.
CPE failures. CPE naming is inconsistent across vendors and versions. The same product may appear under multiple CPE strings.
Version range expressions also do not always capture backported fixes. A distribution that backports a security patch without changing the version number will match a CVE it is not vulnerable to.
Matching failures. Naive version comparison produces both false positives and false negatives. The false positives waste remediation capacity, and the false negatives are the dangerous half.
The practical correction is to treat a CVE match as a hypothesis rather than a finding.
Confirm that the component is deployed, that the vulnerable code path is reachable in your configuration, and that the fix has not been backported.
How CodeAnt AI Closes the Gap CVE Data Leaves Open
A CVE feed tells you about vulnerabilities somebody already found, on a schedule that lags real exploitation. CodeAnt AI covers what that leaves open: the enrichment delay, the matching problem, and the four categories of bug that never get an identifier at all.
1. Correlate three feeds daily, not at scan time
Attack surface management ingests the National Vulnerability Database, the CISA Known Exploited Vulnerabilities catalog, and EPSS scoring, refreshed daily instead of on a scan schedule. Each dependency finding carries its CVSS severity, its EPSS exploit-prediction percentage, and a known-exploited flag, sorted and filterable so a team can triage by exploitability rather than severity alone. That's the enrichment problem solved by holding three feeds side by side rather than depending on any one of them to finish.
2. Score from both sides, and keep it private where it matters
The CodeAnt vulnerability database is the reference layer the platform scores against, built from both sides of the problem: external context (what's actually exposed, reachable, and being probed) correlated against internal context (what you actually run and how it's configured). Internal findings stay private to the account they came from. A verified, externally-reachable exploit pattern doesn't. It gets abstracted and folded back into how every other customer's matching exposure is scored, so a CVE that turns out to be genuinely exploitable in one environment sharpens the ranking for everyone else before it's confirmed in theirs.
3. Find what never got an identifier
CodeAnt's research team has disclosed 150+ CVEs, including CVE-2026-29000, a CVSS 10.0 authentication bypass in pac4j-jwt, and CVE-2026-28292, a CVSS 9.8 remote code execution bug in simple-git, across packages sitting in the dependency tree behind a share of the 2B+ monthly downloads that finding's blast radius covers.
That pac4j finding is the argument for this entire article. A maximum-severity flaw sat in reviewed, open-source, widely deployed code, undetected for six years. And for as long as it went unfixed, every CVE-based tool in the industry reported the affected versions as clean, because no identifier existed yet.
Everything CVE data structurally can't see is what code review, SAST, and penetration testing are for.
The CVE Data Hygiene Checklist
Ingestion
Subscribe to vendor advisories directly for your critical stack, rather than waiting for enriched records to reach your scanner.
Ingest the CISA KEV catalog as a parallel feed, since it is populated on exploitation evidence rather than enrichment status.
Record which CVSS version each score refers to, and whether it came from NVD or the CNA.
Matching
Audit your inventory for undeclared components. Statically linked libraries and files copied into images have no package record and therefore no CVE match.
Check for backported fixes before actioning a version-range match, particularly on long-term-support distributions.
Treat every match as a hypothesis until deployment and reachability are confirmed.
Coverage gaps
Name your blind spots explicitly. First-party code, silently fixed bugs, service-side flaws, and configuration weaknesses receive no CVE.
Cover first-party code with review and SAST, because no vulnerability feed will ever describe it.
Stop Treating CVE Data as the Whole Picture
CVE and NVD data is the backbone of vulnerability management, and it's a backbone with two known fractures: the window between public disclosure and machine-readable enrichment, where your tooling stays silent while your adversary doesn't, and the coverage gap, since the entire system only describes known flaws in versioned third-party products. Take what it reports seriously. Treat what it omits as the actual work.
Where to start this week
Pick your five most critical dependencies and check two things by hand: whether you're subscribed to that vendor's own advisory feed directly, not just waiting for it to reach your SCA tool, and whether a check against the CISA KEV catalog is running as its own lane, separate from your normal CVE triage. Most teams find at least one of those five is missing both.
Running that correlation continuously, against a live NVD, CISA KEV, and EPSS feed, rather than checking it by hand, is what CodeAnt AI's vulnerability database automates. See your real coverage gap →
Related reading
Zero-Day vs N-Day, and the Patch Window: what happens in the gap this article describes.
SBOM Formats, Tools, and the Binary Gap: the inventory side of CVE matching.
The IDOR guide: the most common bug class that CVE data structurally cannot see.
