A security alert lands in your inbox with a string of numbers, a score out of ten, and words like "critical" in bold red. Do you drop everything? Patch at the weekend? Ignore it because the affected software isn't even installed? The answer depends on reading the report properly rather than reacting to the loudest word in the subject line. This guide walks through the pieces of a typical CVE report and explains how to turn them into a decision.
What a CVE Identifier Actually Is
CVE stands for Common Vulnerabilities and Exposures. It is a naming system, not a rating system and not a database of fixes. Each CVE ID looks like this: CVE-2024-3400. The first number is the year the entry was reserved, and the second is a sequential number. That is the whole format. Nothing in the identifier tells you how serious the flaw is.
The point of the scheme is to stop the same bug being called three different things by three different vendors. When a researcher, a vendor, and a national CERT all refer to CVE-2024-3400, everyone knows they mean the same issue. That consistency is why CVE IDs matter even though they carry no severity information on their own.
Two related terms show up constantly alongside CVE IDs:
- CNA (CVE Numbering Authority). The organisation authorised to assign the ID. Often the vendor itself, sometimes a coordinator.
- NVD (National Vulnerability Database). A separate US government catalogue that republishes CVE records and adds its own analysis, including a CVSS score. A CVE may appear in the NVD days after the ID is issued, or occasionally not at all.
If a report cites a CVE ID but you cannot find it anywhere, check the date. Very fresh advisories sometimes get an ID before the public record is enriched with details.
CVSS: The Score Everyone Quotes and Few Read
CVSS stands for Common Vulnerability Scoring System. It produces a number from 0.0 to 10.0. The current widely used version is CVSS 3.1, with CVSS 4.0 gradually appearing in newer records. Scores from different versions are not strictly comparable, so check which version a report used before you compare two numbers.
What the base score ranges generally mean:
- 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.
Those bands are useful shorthand, but the number is not a verdict. It is a summary of a set of judgements about the vulnerability itself, made in isolation from your environment. Two organisations can look at the same 9.8 and reach opposite conclusions about urgency.
The Base Score Metrics That Matter Most
Most CVSS vectors include a compact string such as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. You do not need to memorise it, but four metrics do most of the work:
- Attack Vector (AV). Network means reachable remotely; Adjacent means same network segment; Local means you need a foothold or physical access; Physical means hands on the device.
- Attack Complexity (AC). Low means reliable and repeatable; High means the attacker needs specific conditions, timing, or a race.
- Privileges Required (PR). None means an unauthenticated attacker; Low or High means they need an account first.
- User Interaction (UI). None means no victim action needed; Required means someone must click or open something.
An unauthenticated, network-reachable bug with no user interaction is a genuine emergency if the software is exposed. The same base score on an issue that needs local access and a valid account is far less alarming for most organisations.
Temporal and Environmental Scores
CVSS also has a temporal group, which reflects things like whether exploit code is publicly available or a fix exists, and an environmental group, which lets you adjust the score for your own setup. Vendors and scanners often only publish the base score. If a report shows just one number, assume it is the base score and adjust your thinking accordingly.
Severity Labels Are Not Standardised
Vendors, scanners, and government advisories each apply their own thresholds and their own wording. One vendor's "critical" may map to a CVSS 7.5, while another reserves critical for 9.5 and above. Some advisories use "important" or "moderate" instead of high and medium entirely.
Practical rule: trust the vector over the adjective. If you can find the CVSS vector string, read the metrics. If you cannot, treat the label as a rough hint and look for the specifics below.
What to Check Before You Act
A score tells you about the flaw. The report tells you about your exposure. Work through these questions in order, and stop as soon as one of them rules the vulnerability out.
- Is the affected product actually in use? Include indirect use. A vulnerable library bundled inside a larger application still counts, but only if that code path is reachable.
- Which versions are affected? You may already be patched. Check the exact version string, not the product name.
- Is the vulnerable component exposed? An internal-only service behind authentication is a very different risk from one on the public internet.
- Is there a fix, and how disruptive is it? A trivial update can be scheduled today. A major version jump may need planning.
- Is exploitation happening? Advisories that mention known exploitation in the wild, or inclusion in a widely watched exploited-vulnerability list, should move up the queue sharply.
Only after those five questions should the CVSS number influence how fast you move. It refines urgency; it does not set it.
Reading the Report Body Without Getting Lost
Vulnerability descriptions are dense, but they follow a pattern. Look for the mechanism first: is this remote code execution, privilege escalation, a denial of service, or information disclosure? Remote code execution without authentication is usually the worst case; a denial of service is often annoying rather than catastrophic.
Then look for preconditions. Phrases like "requires the attacker to be authenticated", "only when a specific feature is enabled", or "triggered by a crafted file" are doing heavy lifting. A critical score attached to a feature you have never turned on is not your emergency.
Finally, check references. Vendor advisories usually link to patches and workarounds. Mailing list threads and proof-of-concept repositories can tell you how real the threat is, though treat unverified exploit code with care. Do not run it to find out.
If a vulnerability report does not tell you which versions are affected, what the fix is, and whether exploitation has been seen, you do not have enough to make a decision yet. Go to the vendor advisory.
A Workable Routine
Set a triage habit rather than reacting alert by alert. Log every relevant CVE with its identifier, the affected asset, the CVSS vector, and your exposure judgement. Assign a simple priority: patch now, patch in the next maintenance window, or monitor. Review the monitored pile when new information appears, because exploit availability changes the picture quickly.
Keep an inventory that is good enough to answer "do we run this?" in minutes. Most misjudged vulnerability alerts trace back to an incomplete inventory, not to a misunderstood score. And record why you deprioritised something, so you can defend the decision later and revisit it if circumstances change.
Read the vector, check your exposure, then decide. The number is a starting point, not a sentence.
Photo: Daniil Komov / Pexels