← Glossary

Scoring & Metrics

CVE (Common Vulnerabilities and Exposures)

Also: Common Vulnerabilities and Exposures · CVE ID · CVE identifier · CVE number

Last reviewed:

In one sentence

A CVE is a unique public identifier (like CVE-2021-44228) for one specific software vulnerability, so a bug, a scanner finding, a vendor advisory and a patch note can all point at the same thing without ambiguity.

Why it matters

A CVE ID is a shared name for a flaw. Before it existed, one vendor's "remote code execution in the logging library" was another's "Log4j RCE" and a third's "JNDI lookup bug" — and nobody could tell whether they were talking about one problem or three. A CVE fixes that: CVE-2021-44228 means Log4Shell to your scanner, your SIEM, the vendor advisory and the auditor alike.

What a CVE is not is a priority. The ID tells you a vulnerability exists and gives you a handle to look everything else up — but it says nothing on its own about how severe it is (that is CVSS), how likely it is to be exploited (that is EPSS), or whether you must act now (that is a decision like SSVC). Treat the CVE as the primary key you join all of those to.

How the identifier is structured

The format is CVE-YYYY-NNNNN: the literal prefix, the year the ID was reserved (not necessarily disclosed), and a sequence number of four or more digits. CVE-2023-44487 is the HTTP/2 Rapid Reset flaw; the number carries no meaning beyond being unique.

IDs are issued by CNAs (CVE Numbering Authorities) — MITRE runs the root, but most large vendors (Microsoft, Red Hat, GitHub) and coordinators are CNAs for their own products. A CVE record lists the affected products (often as CPE strings), references, and increasingly the CVSS vector. The NVD then enriches each record with analysis and scoring. Two things worth knowing: an ID can sit in RESERVED state for months before details are public, and IDs are never reused — which is exactly why a CVE is safe to hard-code into a detection or a ticket.

Try it yourself hands-on

You have a list of CVEs from a scan and need to decide what to patch first. Do not start with CVSS — start with exploitation reality.

  1. Open the EPSS Score Lookup and paste your list (it takes up to 100 at once), for example CVE-2021-44228, CVE-2023-44487, CVE-2017-0144. Each row comes back with an EPSS probability, a percentile, and a CISA KEV flag. A KEV hit means the CVE is being exploited in the wild right now — that jumps the queue regardless of its CVSS.
  2. Want the reverse view — "what should I look at today?" — open the Actionable CVEs Dashboard: it lists CVEs newly added to CISA KEV and the highest-EPSS CVEs right now, so you can sanity-check your backlog against what attackers are actually using.
  3. For a specific CVE, pivot on the affected product with the CVE / CPE Search Builder: build the CPE for, say, Apache Log4j 2.x and jump straight to the NVD, GitHub Advisory and OSV records for exact version ranges.
  4. Only now reach for the CVSS v3.1 Calculator to understand how bad a confirmed-relevant CVE is in your environment (environmental metrics), and feed exploitation + impact into the SSVC Decision Tree for a defensible Track / Attend / Act call.

Result: a patch order driven by "is this being exploited and does it reach us", not by a raw severity number that treats an unreachable 9.8 the same as an internet-facing one.

Common misreadings

  • "It has a CVE" is not a severity. Millions of CVEs exist; the ID is a label, not a verdict. Rank with EPSS + KEV + reachability, not by counting CVEs.
  • No CVE does not mean no vulnerability. Zero-days, unpatched vendor bugs and config weaknesses often have no ID. Absence of a CVE is not assurance.
  • The year is the reservation year, not the discovery or disclosure year. A CVE-2021-… can be published in 2024; do not read the year as a timeline.