Vulnerability management is partly a software problem and partly an information problem. Defenders need a shared name for a vulnerability, a measure of its technical severity, evidence of exploitation, and the ability to determine whether the vulnerability affects them.

No single database or score provides all four, so several systems divide the work:

• Common Vulnerabilities and Exposures (CVE) gives each vulnerability a unique identifier.

• Common Vulnerability Scoring System (CVSS) rates its technical severity.

• National Vulnerability Database (NVD) adds product and severity data to CVE records.

• Known Exploited Vulnerabilities (KEV) lists the vulnerabilities that attackers are confirmed to be using.

• Exploit Prediction Scoring System (EPSS) estimates how likely exploitation is in the near future.

A sixth system, Likely Exploited Vulnerabilities (LEV), is a proposed metric rather than a running service. The rest of this part takes them in turn.

Key Organizations

Four organizations maintain the principal systems for naming and tracking vulnerabilities and exploits:

• MITRE Corporation is a nonprofit that operates federally funded research and development centers. MITRE administers the CVE program under sponsorship from CISA, the U.S. Cybersecurity and Infrastructure Security Agency. It also develops the ATT&CK framework, which catalogs the techniques adversaries use.

• The National Institute of Standards and Technology (NIST) is an agency of the Department of Commerce. NIST is responsible for the NVD.

• The Cybersecurity and Infrastructure Security Agency (CISA) is an agency of the Department of Homeland Security. Besides sponsoring the CVE program, CISA publishes the KEV catalog.

• The Forum of Incident Response and Security Teams (FIRST) is an international consortium of response teams drawn from governments, corporations, and universities. FIRST maintains CVSS and the Exploit Prediction Scoring System (EPSS).

Naming Vulnerabilities with CVE

In the early Internet era, researchers reported vulnerabilities through mailing lists or directly to vendors. The same vulnerability could appear under several descriptions, and a defender had no reliable way to determine if the reports referred to the same problem.

The Common Vulnerabilities and Exposures (CVE) system, established in 1999, assigns a standard identifier to each vulnerability in its catalog. A vendor advisory, scanner result, and news article can then use the same name.

Each identifier has the form CVE-[Year]-[Number]. For example, CVE-2024-11477 identifies a 7-Zip vulnerability that can permit code execution when a user opens a crafted archive. The year refers to when the identifier was assigned or reserved, not necessarily when the vulnerability was discovered. Neither the year nor the final number indicates severity.

Scoring Severity with CVSS

A CVE identifies which vulnerability is under discussion. CVSS rates technical severity under a stated set of assumptions. The risk to a particular organization depends on additional factors, such as whether the affected product is installed, whether it is exposed, whether it is mission-critical, and whether another control already protects it.

CVSS combines exploitability and impact characteristics to produce a rating from 0 to 10:

• 0.0: None

• 0.1 to 3.9: Low

• 4.0 to 6.9: Medium

• 7.0 to 8.9: High

• 9.0 to 10.0: Critical

Log4Shell received a CVSS v3.1 base score of 10.0:

CVE-2021-44228 (Log4Shell) Base Score: 10.0 (Critical) Attack Vector: Network (remote) Confidentiality, Integrity, and Availability Impact: High

The current version is CVSS v4.0, published in November 2023. Many records still carry scores calculated under the earlier v3.1 standard. Two scores should be compared only when they originate from the same version. Also, scores come from several publishers, so each score should be recorded along with its source and CVSS version.

NVD and Vulnerability Data

A basic CVE record provides an identifier, a description, affected products, and references. Security tools need more detail to match that record to installed software and help administrators prioritize it.

The National Vulnerability Database (NVD) is maintained by the National Institute of Standards and Technology (NIST), an agency of the U.S. Department of Commerce. NVD enriches selected CVE records with CVSS scores, weakness classifications, and standardized product information. Vulnerability scanners and security platforms have relied on this added data for years.

Publication volume eventually exceeded what one organization could enrich. A backlog emerged in February 2024. NIST reported enriching nearly 42,000 records during 2025, but many records still lacked complete NVD-supplied data. In April 2026, NIST adopted a risk-based model that prioritizes actively exploited vulnerabilities, software used by the federal government, and software designated as critical.

Vendors and other authorized publishers now provide more of the enrichment directly. The result is a distributed system with uneven records. No publisher can determine what a particular organization has installed, so vulnerability management still depends on an accurate local software inventory.

Known Exploited Vulnerabilities (KEV)

A severe vulnerability is not necessarily one that attackers are using. Defenders also need a way to distinguish vulnerabilities that are known to have been used versus those that have merely been published.

The KEV catalog is maintained by CISA. A CVE enters it when reliable evidence shows that attackers have exploited the vulnerability in the wild, which does not mean that every affected product is currently under attack. KEV therefore serves as a priority patch list.

Exploit Prediction Scoring System (EPSS)

KEV records that exploitation has already been confirmed. EPSS asks a different question: how likely is exploitation during the next 30 days?

EPSS is maintained by FIRST and answers it with machine learning trained on observed exploitation data.

An EPSS score of 0.90 represents an estimated 90% probability that one of the EPSS data partners will observe exploitation during that time. EPSS also provides a percentile so that a vulnerability can be compared with other CVEs.

KEV and EPSS complement each other. KEV reports confirmed evidence, while EPSS provides a forecast.

Likely Exploited Vulnerabilities (LEV)

Public evidence of exploitation is incomplete. An attack may have been observed by a company or security provider but not reported to CISA or added to KEV.

NIST proposed Likely Exploited Vulnerabilities (LEV) in Cybersecurity White Paper 41 in May 2025. LEV combines historical EPSS estimates across successive 30-day periods to estimate the probability that exploitation has already been observed. A vulnerability with a modest EPSS score over many periods can therefore accumulate a high LEV estimate even if it never appears in KEV.

LEV remains a proposal. NIST does not provide an official LEV feed, the NVD and federal directives do not use it, and its performance has not yet been measured directly. It is an attempt to estimate a blind spot in confirmed-exploitation catalogs.

The Vulnerability Lifecycle

Vulnerability tracking usually follows the sequence below, although attackers and defenders do not wait for the steps to occur in order:

1. Discovery occurs when a researcher, vendor, or attacker finds a vulnerability.

2. Reporting brings the vulnerability to the vendor. Coordinated disclosure usually gives the vendor time to prepare a fix before public release.

3. Investigation involves the vendor confirming the vulnerability and determining which products and versions are affected.

4. Assignment gives the vulnerability a CVE identifier and an initial description.

5. Publication adds the record to the public CVE list.

6. Scoring describes technical severity with CVSS.

7. Enrichment adds product information, weakness classifications, and other context through NVD or another authorized publisher.

8. Mitigation occurs when the vendor supplies a patch or workaround and administrators apply it.

9. Exploitation tracking uses sources such as KEV to record confirmed attacks and EPSS to estimate future exploitation.

Attackers sometimes exploit a flaw before the vendor or defenders know it exists. The unknown flaw is called a zero-day vulnerability, and an attack that exploits it before defenders have time to prepare is called a zero-day attack. We will cover zero-day attacks when we examine malware. The term explains why exploitation can precede the public tracking process. A missing patch on its own does not make a vulnerability a zero-day: unsupported software may lack patches for vulnerabilities that have been public for years.

Prioritizing What to Fix

No organization can patch every CVE immediately. Defenders combine technical severity with evidence or predictions of exploitation, exposure to attackers, available controls, and the value of the affected asset. A CVSS 9.8 vulnerability on an isolated internal system may deserve less urgency than a 6.5 vulnerability on a public login page.

Naming Attackers, or Who Is Imperial Kitten?

Cybersecurity reporting identifies attacker groups by labels such as Salt Typhoon and Imperial Kitten. It also uses advanced persistent threat (APT) numbers such as APT36. Each label designates a group or a cluster of related activity.

Security companies and government agencies assign these labels. The groups do not select the names themselves. Analysts compare evidence across incidents and name a cluster when they decide that a set of operations shares an operator.

Why Attribution Is Difficult

Attribution is among the hardest problems in the field, and attackers work to keep it that way. Three obstacles recur:

• Public tools and stolen exploits are reused, so the forensic artifacts can implicate many possible operators.

• Operations are conducted through compromised infrastructure. That infrastructure includes cloud servers and home computers belonging to unrelated individuals and organizations.

• Attackers also plant false flags. These are indicators left behind deliberately to direct investigators toward someone else.

The result is that analysts disagree about who did what. Even within a single company, two campaigns may be tracked separately for months and merged later once a connection emerges.

How Vendors Name Them

Vulnerabilities have CVE identifiers, but attackers have no equivalent naming authority. Each security company uses its own scheme:

• Mandiant, now part of Google, has used sequential APT numbers for established groups and UNC numbers for clusters that have not yet been categorized.

• CrowdStrike assigns animal names by geography: Panda for Chinese groups, Bear for Russian groups, Kitten for Iranian groups, and Tiger for Indian groups.

• Microsoft uses weather terms: Typhoon for China, Blizzard for Russia, Sandstorm for Iran, Sleet for North Korea, and Tempest for financially motivated groups. Storm is used for activity still under analysis.

• Older names and numeric placeholders remain in circulation. Lazarus Group, Equation Group, Mandiant’s UNC numbers, and Microsoft’s Storm numbers appear alongside newer names.

The names identify clusters of observed activity, not necessarily a known membership list or legal identity. One adversary may end up with several names. For example, the group behind the SolarWinds compromise has been called APT29, Cozy Bear, and Midnight Blizzard by different organizations.

Attempts at Coordination

The naming systems are a mess, and the companies that created them know it. Microsoft and CrowdStrike announced a collaboration in June 2025 to cross-reference their taxonomies. They reported reconciling more than 80 adversaries, and Microsoft now maintains an actor list that includes other names for each group.

The effort has not produced a single industry taxonomy. In July 2026, Google Threat Intelligence combined the systems previously used by Mandiant and Google’s Threat Analysis Group. Its two-word names encode origin or motivation in the second word: CASTLE for China, ION for Iran, NEPTUNE for North Korea, RELIC for Russia, and COMET for criminal groups. Under that system, APT29 became ICE RELIC. Google retains the older names as searchable aliases.

Tactics, Techniques, and Procedures

Names are inconsistent, and they will remain so. Each vendor observes a different set of incidents and evidence.

An adversary’s tactics, techniques, and procedures (TTPs) remain useful despite the disagreement over names:

• Tactics are broad objectives, such as gaining initial access or exfiltrating data.

• Techniques are general methods for achieving them, such as sending a targeted phishing email or extracting stored passwords from a compromised machine.

• Procedures are specific implementations that can make an operator recognizable, such as a recurring email lure, malware configuration, and arrangement of command servers.

A name can change when a vendor updates a spreadsheet. Recurring infrastructure and recurring methods are the evidence that connects one campaign to another.

Lecture 1: Part 1 | Part 2 | Part 3 | Part 4 Lecture 1 Study Guide | List of terms