A scanner flags a CVE, the score says 9.8, and someone wants to know whether the service comes down tonight. The CVE record is the right place to start, but it is not the place to stop.

Most of the confusion around vulnerability severity comes from treating a database entry as a ruling. It is not one. A CVE tells you that a flaw exists and gives it a name. Working out how bad it is for you, and what to fix first, takes a few more minutes of careful reading.

This covers what the identifiers mean, how CVSS scores are assembled, and how to turn both into a patching order you can justify to your team.

What a CVE identifier actually is

CVE stands for Common Vulnerabilities and Exposures: a public catalogue of identifiers that gives each disclosed flaw a stable name, so vendors, scanners and analysts all refer to the same thing. The format is CVE-YYYY-NNNNN, and the year is the year the ID was reserved or requested. That is not always the year the flaw was published, and it is rarely the year the bug was introduced. Sequence numbers are arbitrary — a higher number does not mean a newer or more serious issue.

IDs are issued by CVE Numbering Authorities: MITRE, NIST, and hundreds of vendors who can assign identifiers for their own products. Quality therefore varies. Some records arrive with exact version ranges and a patch link; others are a one-line description and nothing else.

What a CVE does not promise

Before you build a queue around a record, remember it is not:

• A severity rating. The score is added later, by NVD or the vendor.
• Proof of exploitation. A large share of published CVEs are never used in the wild.
• A fix. It is an identifier that helps you find the vendor's fix.
• Permanent. Records get updated, disputed and rejected. A rejected CVE is not a valid vulnerability, so drop it from your list.

Some vendors publish advisories without a CVE, and some flaws never get a record. Missing identifier does not mean safe.

Reading the record: the fields that matter

Open the record on the CVE Program's site or the NVD entry and work through it in the same order every time. A fixed routine stops you from overreacting to a dramatic description and missing the useful details.

• Status and dates. "Rejected" or "Disputed" saves you an afternoon. Check the last-modified date too; older records are often rewritten.
• Description. Look for the component and the class of flaw: memory corruption, authentication bypass, deserialization, path traversal.
• Affected versions or CPE entries. The references usually point to the vendor advisory, which has precise version ranges and any required conditions.
• CWE. The weakness class, handy for spotting recurring patterns in your own codebase.
• CVSS vector. The score's ingredients, and more informative than the number on its own.

If the description and the vendor advisory disagree, trust the vendor first. Descriptions are often written before the full picture is known and are not always revised.

CVSS: what the score is built from

CVSS produces a number from 0.0 to 10.0 plus a vector string. Version 3.1 is still the most widely published; version 4.0 reorganises the metric groups but keeps the familiar range and severity bands.

The bands

• None: 0.0
• Low: 0.1 – 3.9
• Medium: 4.0 – 6.9
• High: 7.0 – 8.9
• Critical: 9.0 – 10.0

Decoding a vector

Here is a base vector you will see often: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. It scores 9.8. Reading it left to right:

• AV:N — network. Exploitable remotely.
• AC:L — low complexity. No special conditions required.
• PR:N — no privileges needed.
• UI:N — no user interaction. Nobody has to click anything.
• S:U — scope unchanged. The flaw stays inside the vulnerable component.
• C:H / I:H / A:H — high impact on confidentiality, integrity and availability.

Change one metric and the number moves. Swap AV:N for AV:L, meaning local access is required, and that same flaw drops to 7.8. The vector tells you what "critical" is actually claiming about your deployment.

CVSS also defines Threat and Environmental metric groups. Base scores assume a worst-case default. Environmental metrics let you adjust for your own setup — lower the impact if the component sits behind authentication, for instance. Most teams never fill them in, which is part of why a base score so often feels wrong.

Severity is not risk

This is the most useful idea in the whole discipline. CVSS measures severity: how bad the flaw is in the abstract. Risk depends on your asset, your exposure, and whether anyone is exploiting it right now.

Log4Shell, CVE-2021-44228, scored 10.0. That number was correct, and it still was not equally urgent everywhere. A Java service exposed to the internet with logging enabled had a fire on its hands. A legacy internal application on an isolated network had a scheduled maintenance task.

Four questions to ask before you let a score dictate your night:

• Is the affected component reachable from where an attacker would start?
• Does exploitation need credentials, user interaction, or a non-default configuration you do not use?
• What data or access does the vulnerable process hold?
• Is there a working public exploit, and is anyone using it?

A 9.8 in an unreachable lab virtual machine can wait for the normal cycle. A 6.5 on the internet-facing VPN concentrator usually cannot.

Signals that sharpen the decision

Scores are static; exploitation is not. Three sources help you separate noise from urgency.

• CISA's Known Exploited Vulnerabilities catalogue. If a CVE appears there, exploitation has been observed. Treat it as urgent regardless of the number.
• EPSS scores. A probability estimate that a CVE will be exploited in the next 30 days. Best used to rank a long list, not to decide on a single item.
• Vendor advisories and VEX statements. They confirm which products and versions are affected, and sometimes state plainly that a product is not affected.

A workable combination: severity band for the first sort, KEV membership as an override, EPSS to order everything that remains.

A ten-minute triage routine

1. Check the status. Rejected or disputed records leave the queue immediately.
2. Open the vendor advisory, not just the CVE. Note the affected versions and any configuration that has to be present.
3. Confirm you actually run it. Inventory beats assumption — a scanner finding a package name does not prove the vulnerable code path ever executes.
4. Look for exploit signals: KEV, EPSS, a public proof of concept, alerts from your own monitoring.
5. Judge exposure: internet-facing, authenticated, internal only, air-gapped.
6. Choose an action: emergency patch, next maintenance window, compensating control such as a WAF rule or disabled feature, or a documented acceptance.
7. Write down the reasoning. When the same CVE appears in next month's scan, that note ends the conversation in seconds.

Getting better at this

Read a handful of CVE records each week from products you actually run. Start with the vendor advisory, then the vector, then the exploitation signals. Within a month, a 9.8 will stop being a panic number and start being a set of facts you can weigh.

Two habits carry most of the weight: keep a software inventory that is roughly accurate, and subscribe to vulnerability feeds filtered to your own stack so you are not scrolling through thousands of records that have nothing to do with you. If your patching deadlines are set by a contractual or regulatory framework, confirm the exact requirements with whoever owns compliance in your organisation — the risk judgement is yours, the obligation may not be.

Photo: Al Nahian / Pexels