CVE, NVD and KEV: How Vulnerability Tracking Evolved

CVE is not a patch database, scanner or risk score. It is a shared identifier for a specific publicly disclosed vulnerability. It emerged because security databases, vendors and tools used different names for the same defect. Teams could not reliably determine whether a scanner alert, vendor advisory and IDS signature referred to one problem.

The current ecosystem has several layers. CVE identifies, a CNA publishes the record, NVD enriches it, CVSS describes technical severity, EPSS estimates exploitation probability, and CISA’s KEV Catalog indicates confirmed exploitation. Confusing those roles produces poor priorities.

Before CVE: disclosure without a common language

During the 1990s, vulnerability information travelled through mailing lists, vendor archives, CERT and independent databases. Bugtraq, created in 1993, became a major public forum for technical disclosure. Posts could include affected versions, workarounds and demonstration code. Open discussion accelerated fixes while creating debate over timing and detail.

Full disclosure argued that public pressure drives vendor response and informs users. Coordinated disclosure gives a vendor time to prepare a fix. Both address an asymmetry: discoverers, vendors, users and attackers have different incentives and deadlines.

Operationally, naming remained a problem. One buffer overflow might have several labels, making automation and comparison unreliable.

1999: CVE is launched

MITRE’s David E. Mann and Steven M. Christey presented the common-enumeration concept at a Purdue workshop in January 1999. A working group formed and created 321 initial records. The CVE List launched publicly in September 1999.

It was intentionally a dictionary rather than a universal knowledge base. An identifier in the form CVE-year-number lets multiple parties point to one vulnerability. Descriptions and references may evolve while the identifier remains the correlation point.

As product volume grew, the programme expanded CVE Numbering Authorities. Vendors, coordinators and other authorised organisations reserve IDs and publish records within defined scope. Federation scales the system while creating differences in record speed and detail.

CVE record lifecycle

A discoverer reports a defect to a vendor, coordinator or CNA.
The CNA checks scope and potential duplication.
An ID becomes RESERVED; a number exists but details are not public.
The CNA publishes description, affected versions and references; status becomes PUBLISHED.
The record may be updated or marked REJECTED, for example when it duplicates another record.

RESERVED does not prove a secret zero-day. IDs may be reserved ahead of publication. REJECTED numbers remain visible so tools know not to reuse or trust them.

NVD enriches CVE data

NIST’s National Vulnerability Database ingests CVE records and adds data such as CPE product mappings, CWE weakness classes and CVSS assessments. An NVD record may be awaiting analysis even when the CVE is already public. Missing NVD scoring is not evidence that no vulnerability exists.

NVD has existed in some form since 1999, and NIST notes that older records—particularly before 2015—may contain less detail. CPE mappings should not be treated as a perfect inventory because names and version boundaries can be incomplete.

Defenders should combine the CNA record and vendor advisory with local evidence of version and configuration. NVD helps correlate; it does not prove local exposure.

CVSS severity is not organisational risk

The Common Vulnerability Scoring System was created because vendors used incompatible scales. FIRST became its custodian in 2005. A base score describes technical properties such as attack vector, complexity, required privileges, user interaction and impact.

CVSS does not know whether a product is Internet-facing, holds critical data, has active exploitation or is protected by a compensating control. A 9.8 score signals serious technical characteristics in the assumed scenario, not automatically the first item in every remediation queue.

Local priority requires:

confirmed vulnerable product and version;
reachability from the attacker’s position;
asset value and business impact;
exploitation evidence or credible exploit availability;
existing controls and safe remediation cost.

2021: CISA KEV changes prioritisation

On 3 November 2021, CISA issued Binding Operational Directive 22-01 and created the living Known Exploited Vulnerabilities Catalog. KEV entries have credible evidence of active exploitation and an available remediation action. The directive binds US federal civilian agencies to deadlines, while CISA recommends the catalogue to all organisations.

KEV addresses scale. Thousands of high CVSS scores compete for attention, while attackers exploit a subset. KEV membership is a strong operational signal. Teams still confirm that the product exists locally, but should not wait for perfect analysis.

KEV is not a list of every exploited flaw in the world; entries require evidence and process. Absence does not mean safety. Presence means “no exploitation evidence” is no longer a valid argument.

EPSS, SSVC and richer decisions

FIRST’s Exploit Prediction Scoring System uses a statistical model to estimate the probability of CVE exploitation in a near-term window. EPSS changes over time and does not measure impact. High probability on a low-impact asset and lower probability on a safety-critical asset demand different decisions.

CISA and SEI’s Stakeholder-Specific Vulnerability Categorization uses a decision tree incorporating exploitation, technical impact, mission value and available action. Mature programmes combine KEV for confirmed exploitation, EPSS for probability, CVSS for technical properties and local context for impact.

PoC code: evidence and hazard

A proof of concept can validate root cause and support safe retesting, but public code lowers attacker cost. A repository labelled “PoC” is not inherently safe; fake exploit repositories have distributed malware.

Defenders should review code, execute in isolation, pin a commit and never test production without permission. When a version check or non-invasive probe is enough, a full exploit adds unnecessary risk. This is part of disciplined vulnerability management.

Common programme failures

Counting CVEs rather than measuring exposure-reduction time.
Treating CVSS as business risk.
Missing asset owners and remediation deadlines.
Closing findings after patch installation without retesting.
Ignoring edge appliances and agentless software.
Exceptions without compensating control and review date.
Scanning without complete inventory.

A good workflow ends with evidence: corrected version, changed configuration, unreachable attack path and retest record. A web penetration test complements scanning by determining whether several moderate weaknesses form a critical chain.

Log4Shell tested the entire ecosystem

Disclosure of CVE-2021-44228 in Apache Log4j showed that an identifier is only the beginning. Organisations had to establish whether the library appeared directly in an application, nested inside a Java archive, bundled in a vendor product or inherited by a container image. A server list was insufficient. Response required component inventory, vendor communication, exploitation monitoring and repeated updates as guidance evolved.

The US Cyber Safety Review Board described Log4j as an endemic vulnerability likely to remain in systems for years. It illustrates the gap between publishing a CVE and reducing exposure. A software bill of materials programme helps locate dependencies, but the SBOM must be current and connected to deployed assets.

From alert to closure: a minimum workflow

For a significant CVE, a team should verify the CNA or vendor advisory; map versions to active assets; establish reachability; check KEV and exploitation telemetry; assign an owner; choose a patch or compensating control; perform a safe retest; and retain evidence plus an expiry date for any exception.

Internet-facing edge appliances need a faster route because internal segmentation does not protect their management surface and attackers scan them automatically. External attack-surface management can discover unmanaged exposure. A vulnerability disclosure programme gives researchers a safe channel before information circulates without coordination.

Metrics should reflect outcomes. Useful measures include time from publication to asset identification, time from KEV addition to mitigation, percentage of exceptions with valid compensating controls and retest success. Raw CVE totals reward discovery and inventory growth, so they can look worse even when the programme improves.

Frequently asked questions

Is every CVE dangerous?

No. A CVE identifies a vulnerability, while risk depends on product presence, configuration, exposure, asset importance and attacker activity.

Who assigns CVE IDs?

Authorised CVE Numbering Authorities—including vendors and coordinators—publish within their scopes. MITRE has a key programme role, but the assignment model is federated.

Are NVD and CVE the same thing?

No. The CVE Program creates identifiers and records. NVD ingests and enriches them with data such as CVSS, CWE and CPE.

What should be patched first?

Prioritise confirmed vulnerable assets under active exploitation, especially Internet-facing and critical ones. Then combine exploit probability, impact, reachability and controls. CVSS order alone is insufficient.

Sources

Need to find which vulnerabilities create a real route to data? Book a penetration test with impact validation and safe retesting.