What does a CVSS 9.8 score tell you, and what does it miss?

A CVSS score such as 9.8 tells you how severe a flaw is in general: how easy it is to attack and how much damage is possible. It does not tell you whether attackers are using it, whether your system is exposed, or how much the affected system matters to you.

TL;DR

• CVSS is a 0 to 10 severity score maintained by FIRST, a non-profit.
• The base score measures the flaw itself. FIRST says it should not be used alone to assess risk.
• Add three checks: is it being exploited, is it reachable in your setup, and how important is the system.
• A 9.8 can wait. A 6.5 can be urgent. Context decides.

What is CVSS, in plain language?

CVSS stands for Common Vulnerability Scoring System. FIRST describes it as an open framework for communicating the characteristics and severity of software vulnerabilities. A vulnerability is a flaw in software that someone could misuse. A score is a number from 0 to 10 that sums up how severe that flaw is.

Think of a weather alert that says "Category 5 storm." It tells you how strong the storm is. It does not tell you whether the storm is heading toward your town. CVSS works like the category label. It describes the storm, not your location.

The score comes with a vector string, a short line of letters that records the inputs behind the number, such as whether the attacker needs to be on the same network and whether a user must click something. FIRST asks that anyone publishing a CVSS score also publish the vector so others can see how it was reached.

What do the severity labels mean?

FIRST publishes a simple scale that turns the number into a word.

FIRST notes that using these labels is optional. They exist to help organizations assess and prioritize. They are a starting point, not a verdict.

Why is a CVSS score not the same as risk?

The CVSS user guide for version 4.0 is direct about this. It says base scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk. The base score represents only the intrinsic qualities of the flaw and is independent of any factor tied to threats or to the environment where the vulnerable system lives.

In everyday terms, risk is the chance that something bad happens to you, multiplied by how bad it would be. Severity is only one ingredient.

CVSS has four metric groups.

• Base: qualities of the flaw that do not change over time.
• Threat: qualities that change over time, such as whether exploit code now exists.
• Environmental: qualities unique to your setup.
• Supplemental: extra context that does not change the score.

Here is the catch. The guide says organizations such as the National Vulnerability Database typically provide only the base score. The threat and environmental parts are left to you, the person using the score. FIRST suggests naming scores to show what went in, for example CVSS-B for base only and CVSS-BTE when base, threat and environmental metrics are all used. So a 9.8 you see in a scanner is very likely a base score. It is the storm category, not your forecast.

What should you check after the score?

Use three follow up questions. Each one answers something CVSS leaves open.

Is anyone exploiting it?

The CISA Known Exploited Vulnerabilities catalog lists flaws with reliable evidence of active exploitation. To be listed, a flaw needs a CVE ID, reliable evidence of exploitation in the wild, and a clear remediation action. CISA tells organizations to use the catalog as an input to their prioritization.

A second signal is EPSS, the Exploit Prediction Scoring System. It estimates the probability, from 0 to 1, that a flaw will be exploited in the wild in the next 30 days, and it is published daily and free. FIRST is clear that EPSS is not a complete risk score either. It does not measure damage or whether your environment is affected.

For a side by side view, see CVSS, EPSS and KEV explained and EPSS scores in plain language.

Can the flaw be reached in your setup?

Many flaws sit in code your program never runs, or in a service that is not exposed to the internet. A critical flaw in a part you do not use is far less urgent than a medium flaw on a public login page. Our guide on reachability analysis explains how to check.

How much does the system matter?

A flaw on a test server that holds no data is different from the same flaw on the server that takes customer payments. Give each system a rough importance of high, medium or low and use it as a tiebreaker.

A worked example with invented numbers

These numbers are invented to show the thinking. They are not from a real incident.

Two flaws appear in your scan on the same Monday.

Going by CVSS alone, you would fix A first. Going by the full picture, you fix B first. Flaw B is being used in real attacks, sits on a front door, and guards something important. Flaw A still gets fixed, but on a normal schedule.

Notice that the 1 percent EPSS figure is not zero. Per FIRST, most flaws are never exploited, so a low number is a prediction and not a promise. That is why Flaw A is scheduled and not ignored.

How do you use this in a weekly routine?

1. Sort by the exploited list first. These go to the top.
2. Within the rest, filter out what is not reachable or not exposed.
3. Use CVSS severity and EPSS to order what remains.
4. Break ties with system importance.
5. Write down the decision for anything you defer, with a review date.

If you want a longer ranking method, read how to prioritize vulnerabilities and risk based vulnerability management explained.

Try it yourself

Click through it at your own pace, or open it full screen. Look for how a high severity score and a real exploitability signal can point in different directions.

How can Safeguard help?

Safeguard scans dependencies and builds an SBOM, then applies reachability analysis so you can see which flaws sit in code that your application actually uses. Policies and gates let you encode your own rules, for example "block a pull request that adds a flaw on the known exploited list." You can try the free scan at gold.safeguard.sh/scan to see severity and context next to each other.

Quick check

Sources

• FIRST, CVSS v4.0 User Guide
• FIRST, CVSS v4.0 Specification Document
• FIRST, EPSS Frequently Asked Questions
• CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities

Last reviewed: 19 October 2026.