CVSS Score vs Real Risk: Why a 9.8 Critical Might Be Safe to Ignore

TL;DR

1. CVSS measures severity. It describes how bad a vulnerability could be in a worst case. FIRST, the group that runs CVSS, says the base score should be combined with threat and environment information before you use it to judge risk.
2. Three questions turn severity into risk: Is anyone exploiting it? Can an attacker reach it in your setup? What else stands in the way?
3. Very few high scores get exploited. EPSS data shows that only 2.3% of CVEs scored 7 or above were seen in exploitation attempts in a given month.
4. A 9.8 can wait if it's unreachable, unexploited and covered by other controls. A 7.5 on your login page that attackers are using right now cannot.
5. "Ignore" means deprioritize in writing.
6. For SOC 2, record why you made the call, who approved it and when you'll check again.

Your scanner sends a report. There's a red banner at the top: CRITICAL, CVSS 9.8. Someone posts it in Slack with three fire emojis. The CTO cancels lunch.

Then someone checks and finds the vulnerable code sits in a library feature you never call, on a server that isn't connected to the internet, behind two layers of login. The score is accurate, but nobody needed to cancel lunch.

This post explains why the CVSS score tells you how bad a vulnerability could be, but not how much danger you're actually in, and how to tell the difference without ignoring something that really matters.

What does a CVSS score actually measure?

It measures how bad a vulnerability is in a generic, worst-case setup. The base score looks at things like whether an attacker needs to log in, whether they need someone to click a link, and how much damage they could do.

What it can't know is anything about you. It doesn't know whether the vulnerable software faces the internet, whether you even use the vulnerable feature, or whether attackers are using it this week.

FIRST, the organization that maintains CVSS, says so directly in its v4.0 user guide. Base scores "are designed to measure the severity of a vulnerability" and should be supplemented with an analysis of your environment and with threat information that changes over time.

Think of CVSS as a car's top speed. A car that can do 250 km/h is dangerous in theory. If it's parked in a locked garage with no keys and flat tyres, it's not your biggest road safety problem.

Is anyone actually exploiting it?

This is the first question to ask, and two free resources help answer it:

1. CISA's Known Exploited Vulnerabilities (KEV) catalog. The US Cybersecurity and Infrastructure Security Agency lists vulnerabilities with confirmed exploitation in the wild. If a CVE is on the KEV list, attackers are already using it.
2. EPSS (Exploit Prediction Scoring System). Also run by FIRST, EPSS gives each CVE a score from 0 to 1 that estimates the probability it will be exploited in the wild in the next 30 days.

The numbers are humbling. EPSS data reproduced by Orca Security shows only 2.3% of CVEs scored CVSS 7 or above were seen in an exploitation attempt during the month checked. If you treat every "high" or "critical" as an emergency, most of your emergencies will never happen.

  Example: your scanner flags a 9.8 in a little-known image library. It's not on the KEV list, there's no public exploit code, and its EPSS score is 0.002. Meanwhile, a 7.5 in your VPN appliance has been on the KEV list since Tuesday. Fix the VPN first.

Can an attacker even reach it?

A vulnerability only matters if an attacker can get to it. Check three things:

1. Is the system internet-facing? A flaw in your public web app is reachable by anyone. A flaw on a build server that only exists inside a private network is much harder to reach.
2. Is the vulnerable code actually used? Many scanners flag a whole library even when your code never calls the vulnerable function. If the flaw is in a library's XML parser and you only use its date formatting, the risk is much lower.
3. Is the vulnerable feature turned on? Some flaws only work when a specific module or setting is enabled. If it's switched off in your setup, the attack doesn't work.

  Example: a 9.8 remote code execution flaw in a web server module. Your production servers run that web server, but the module is disabled and the servers sit behind a load balancer that only forwards traffic to your app. It still needs fixing, but it can wait for the next scheduled patch.

One warning: "it's internal" is the most popular excuse in security, and sometimes it's wrong. Attackers who get in through a phishing email are also internal. Lower the urgency for internal systems, but don't take them off the list.

What else is standing in the way?

Compensating controls are the other defences that make a vulnerability harder to use, even before you patch it. Common ones include:

1. Network controls. Firewall rules, private subnets or security groups that block traffic to the vulnerable port.
2. Strong authentication. If the flaw needs a logged-in user, SSO with MFA raises the bar a lot.
3. A web application firewall (WAF). Many WAF vendors publish rules that block known exploit patterns within days of a big disclosure.
4. Least privilege. If the vulnerable service runs with minimal permissions, a successful attack can do far less damage.
5. Monitoring and alerts. These don't stop the attack, but they shorten how long an attacker goes unnoticed.

  Example: a 9.8 in an internal admin dashboard. It sits behind your VPN, requires SSO with MFA, and only six people have access. A WAF rule already blocks the known exploit pattern. The underlying flaw is still serious, but an attacker would have to get past three other controls first. That makes it a candidate for your normal patch cycle rather than a weekend call-out.

The important part is to write it down. A compensating control that only exists in someone's head doesn't count, either for auditors or for whoever is on call when it fails.

So how do you decide what to fix first?

Ask the three questions in this order:

1. Can an attacker reach it? If not, deprioritize it. Write down why, and check again when your setup changes.
2. Is it being exploited? If it's on the KEV list or has a high EPSS score, fix it now, measured in hours or days.
3. Are compensating controls in place? If yes, fix it on your normal timeline. If no, fix it within your critical timeline.

The result is a list where the urgent items are actually urgent. Your engineers stop getting paged for theoretical problems, and they start trusting the alerts again. That second part is worth more than any scanner subscription.

One rule overrides everything: if you can't answer one of the three questions, treat the answer as the worst one. "We don't know if it's reachable" counts as reachable.

What does SOC 2 say about this?

SOC 2 doesn't tell you to fix everything by CVSS score. CC7.1 asks you to find vulnerabilities and fix them in a "timely" way, and your policy defines what timely means.

That gives you room to prioritize by real risk, as long as your policy says you do and your records show it. Auditors usually want to see:

1. A policy that explains how you rate risk. If you adjust severity for exposure and exploitation, say so.
2. A record for each deprioritized critical or high. Include the reason, the compensating controls, who approved it and when you'll check again.
3. Follow-up. Show that you actually rechecked the item on the date you set.

What auditors don't like is a 9.8 that's been open for a year with no explanation. That looks like you missed it, even if you had good reasons. A written risk acceptance shows you made a decision.

FAQs

What's the difference between CVSS and EPSS?

CVSS rates how severe a vulnerability could be. EPSS estimates how likely it is to be exploited in the next 30 days. FIRST runs both, and they work best together.

Is it ever safe to ignore a critical vulnerability?

You can safely put it lower on the list if it's unreachable, not being exploited and covered by other controls. You shouldn't ignore it with no record. Document the decision and set a date to check again.

What is the CISA KEV catalog?

A list kept by the US Cybersecurity and Infrastructure Security Agency of vulnerabilities with confirmed exploitation in the wild. Anything on it should go to the top of your list if it affects a system you run.

Doesn't CVSS v4.0 already account for exploitation?

CVSS v4.0 has Threat and Environmental metrics that can adjust the score. Most scanners still show only the base score, so you usually need to add that context yourself.

How often should we recheck a deprioritized vulnerability?

At least when your setup changes, when the KEV list or EPSS score changes, and on a fixed schedule such as monthly or quarterly.

Will an auditor accept risk-based prioritization?

Generally yes, if your policy describes it and you keep records for each decision. What they won't accept is an old critical with no explanation.

Drowning in criticals?

Book a free 45-minute gap analysis with CloudSapio. We'll look at how you rate and track vulnerabilities, show you how to prioritize by real risk, and make sure your records will hold up in a SOC 2 audit.



Book my free gap analysis

Ready to move faster?

Too much to do,

too important to ignore.