What is a CVE? Vulnerability basics

You'll see them in security advisories, dependency alerts, and news headlines: codes like CVE-2024-12345. They're the common language the whole industry uses to talk about software vulnerabilities. Understanding them is the first step to actually managing your security risk.

What a CVE is

A CVE (Common Vulnerabilities and Exposures) is a unique public identifier for a specific security vulnerability in software. When a flaw is discovered, it's assigned a CVE ID so that everyone — vendors, researchers, defenders — can refer to the exact same issue.

The format is simple:

CVE-2024-12345
    │    │    │
   "CVE" year  unique number

Before CVEs, the same bug might have five different names across five vendors. The CVE gives it one canonical identity, so a patch, an advisory, and a scanner all point to the same thing.

How severity is scored (CVSS)

Not all vulnerabilities are equal. Each CVE typically gets a CVSS (Common Vulnerability Scoring System) score from 0 to 10, reflecting how serious it is:

CVSS score	Severity
0.1 – 3.9	Low
4.0 – 6.9	Medium
7.0 – 8.9	High
9.0 – 10.0	Critical

The score factors in things like how easy it is to exploit, whether it needs authentication, and the impact if exploited. A Critical CVE that's easy to exploit remotely is the kind that demands you patch today.

Why CVEs matter to you

Even if you never write a line of vulnerable code yourself, you almost certainly use vulnerable code — every dependency, library, and tool can have CVEs:

A CVE in a framework or library you depend on affects you.
A CVE in your server software, OS, or container base image affects you.
A CVE in a third-party service can affect your data.

This is the heart of supply-chain security: your security is only as strong as the weakest dependency in your stack.

How to stay on top of them

You can't fix what you don't know about. The practical workflow:

Know your dependencies. Keep an inventory of what you use (an SBOM — software bill of materials — formalises this).
Scan continuously. Use dependency scanners (built into many code hosts) that flag known CVEs in your packages.
Prioritise by severity and exposure. A Critical CVE in something internet-facing beats a Medium in something internal. Patch the dangerous, reachable ones first.
Patch promptly. Most breaches exploit known vulnerabilities with patches already available — the gap is time-to-patch.

The uncomfortable statistic: a huge share of real-world breaches exploit known CVEs that had a fix available. The vulnerability isn't usually the surprise — the unpatched vulnerability is. Speed of patching is the game.

A monitoring connection

While CVE management is about patching, monitoring is about knowing your systems are healthy — and the two meet during an incident. If exploiting a CVE takes your service down, uptime and error monitoring is what tells you something's wrong, fast, so you can respond.

The bottom line

	In one line
What	A unique public ID for a specific software vulnerability.
Severity	Scored 0–10 via CVSS (Low → Critical).
Why care	Your dependencies have CVEs — your stack inherits them.
Do	Inventory, scan, prioritise by severity + exposure, patch fast.

A CVE is the industry's shared name for a known flaw — and the ones that hurt are the known flaws you didn't patch in time. Track your dependencies, scan continuously, and patch the critical, exposed ones first.