Security
CVEs and Vulnerability Scoring
A CVE (Common Vulnerabilities and Exposures) is a standardized ID assigned to one specific, publicly known security vulnerability — nothing more. "CVE-2021-44228" means exactly one thing to every security team, vendor, and tool on the planet, which is the entire point: before CVEs existed, everyone described the same vulnerability differently, making it genuinely hard to know if two reports were even talking about the same bug.
- What it is
- A unique identifier (CVE-YYYY-NNNNN) for one specific vulnerability, plus a separate CVSS score describing how severe it is.
- Mental model
- A CVE ID is a case number — it identifies which vulnerability everyone is discussing, but says nothing about severity on its own. CVSS is the separate scoring system for that.
- Key numbers
- CVSS scores run 0.0–10.0 across None/Low/Medium/High/Critical bands; tens of thousands of new CVEs are published every year.
- Reach for it when
- Evaluating whether a dependency, library, or device is affected by a known vulnerability, or deciding which of several known issues to fix first.
What a CVE actually identifies
A CVE ID has the format CVE-YYYY-NNNNN — the year it was
assigned (not necessarily the year it was found or
disclosed), and a sequence number. IDs are issued by
CNAs (CVE Numbering Authorities) — MITRE itself, plus
hundreds of software vendors, security researchers, and open-source
projects authorized to assign IDs directly for their own products.
A CVE record itself is deliberately minimal: a description of the
vulnerability, the affected product(s) and version range, and
references to advisories or patches — it's an index entry, not the
full technical writeup.
The CVE lifecycle
CVSS: turning a vulnerability into a score
A bare CVE ID says nothing about severity — that's CVSS's (Common Vulnerability Scoring System) job, built from several independent metrics describing how the vulnerability can actually be exploited:
| Metric | Question it answers |
|---|---|
| Attack Vector | How is it reached — over the network, only from an adjacent network, only locally, or only with physical access? |
| Attack Complexity | How hard is reliable exploitation — low effort, or does it depend on conditions outside the attacker's control? |
| Privileges Required | Does the attacker need to already be authenticated, and at what level? |
| User Interaction | Does a victim have to do something (open a file, click a link) for it to work? |
| Confidentiality / Integrity / Availability impact | If exploited, how badly is each of these three properties affected — none, low, or high? |
These combine into a single base score from 0.0 to 10.0. A network-reachable vulnerability needing no authentication and no user interaction, with high impact on all three of confidentiality, integrity, and availability, scores at the very top of that range — exactly the shape of a handful of infamous real-world vulnerabilities (the 2021 Log4Shell vulnerability in the widely-used Log4j logging library is a commonly cited example: remotely triggerable, no authentication needed, full system compromise).
Severity bands
| Score range | Severity |
|---|---|
| 0.0 | None |
| 0.1 – 3.9 | Low |
| 4.0 – 6.9 | Medium |
| 7.0 – 8.9 | High |
| 9.0 – 10.0 | Critical |
Where to actually look them up
- NVD (National Vulnerability Database)
- The U.S. government-run database that enriches raw CVE records with CVSS scores, affected-product data, and references — usually the first stop for looking up a specific CVE ID.
- Vendor security advisories
- Often published alongside or ahead of the CVE record itself, with vendor-specific remediation guidance the generic CVE record won't have.
- GitHub Security Advisories
- Ecosystem-specific advisories (npm, PyPI, and others) frequently linked to a CVE, surfaced directly in a repository's own dependency graph.
Real-world applications
- Patch prioritization — CVSS scores let a team triage a backlog of known issues by actual exploitability and impact rather than by however loud each report sounds.
- Vendor/procurement risk assessment — a vendor's CVE history and typical time-to-patch is real, checkable due-diligence data before adopting their component.
- Embedded device long-tail support — a device shipped years ago can still be affected by a CVE published against a library it embeds, long after anyone remembers that library is even in there.
- Automotive and IoT fleet risk — a CVE in a component used across an entire deployed fleet (see IoT Architecture) can mean a coordinated OTA response, not just a single device fix.
Gotchas
- A CVE existing doesn't mean a working exploit is public, and a high CVSS score doesn't automatically mean your specific deployment is exposed — the score assumes a generic worst-case configuration, not your actual network topology or mitigations.
- "CVE assigned" and "patch available" are two different milestones — a reserved or recently disclosed CVE can sit unpatched for a real, sometimes long, window.
- Embedded devices with multi-year field lifespans and no active CVE-monitoring process are a genuinely common blind spot — a library baked into firmware years ago doesn't stop being a target just because nobody's watching its CVE feed anymore.
- A CVE's year prefix is when the ID was assigned, not necessarily when the vulnerability was introduced or even discovered — don't assume a "CVE-2015-..." only affects old software.