Why a CVSS score cannot prioritise your cloud risk
A Critical result on a resource nobody can reach is noise. A Medium one, one hop from your production database, is how estates get breached.
The Common Vulnerability Scoring System (CVSS) rates a single vulnerability from 0.0 to 10.0 based on how it can be exploited and what it affects. It is computed once, without any knowledge of your environment. So it cannot tell you whether a flaw is reachable, or what an attacker would reach next.
CVSS is a good standard. It is widely adopted and it answers a real question. The problem is that the question it answers is not the one you are asking when you decide what to fix on Monday morning.
What CVSS actually measures
A CVSS base score describes the intrinsic characteristics of a flaw: whether it can be triggered over the network, how complex the attack is, whether it needs privileges or user interaction, and how badly confidentiality, integrity and availability suffer if it succeeds.
Every one of those is a property of the vulnerability. Not one of them is a property of your estate. The base score is set by whoever publishes the advisory, before they have ever seen your account.
CVSS v4.0, published by FIRST in late 2023, does include Threat and Environmental metric groups. In principle the Environmental group lets you adjust a score for your own context. In practice almost nobody fills it in per asset, because doing that by hand across thousands of results is not realistic. What lands in most queues is still the base score.
The two things it cannot know
1. Reachability
Whether an attacker can get to the vulnerable component at all. A 9.8 on an instance in a private subnet with no ingress, no public load balancer in front of it, and no route from anything internet-facing is a 9.8 that nobody can touch. The score does not change. The risk is close to zero.
Turn it around. A moderate flaw on a host that terminates public traffic is a live entry point. Same severity arithmetic, completely different urgency.
2. Blast radius
What the compromised component can reach next. The CVSS scope metric gestures at this, but only within the vulnerable system. It has no concept of the IAM role that instance can assume, the secrets in that role's reach, or the database those secrets open. That outward reach has its own name and its own maths, covered in how blast radius is actually measured.
What an attack path is instead
An attack path is a concrete, ordered route through your environment: a sequence of real edges from an entry point an attacker can use, to something worth taking. Each hop is a relationship that exists in your configuration right now. We go through the parts one by one in what an attack path is and how it is built. Here is one, read as a sequence:
- An internet-facing EC2 instance runs an unpatched service. That is initial access.
- The instance can assume an IAM role carrying a wildcard policy. That is privilege escalation.
- The role can invoke a Lambda whose environment variables hold a database password in plain text. That is credential access.
- Those credentials reach an RDS instance from a subnet that allows it. That is lateral movement.
- The database holds customer records. That is the objective.
Now look at what each hop scores in a flat list. The wildcard IAM policy is a configuration problem, not a CVE, so it may carry no CVSS score at all. The plain-text environment variable is often filed as "medium, secret in config". Neither would sit near the top of a queue sorted by severity. Together they are the entire breach.
Why the ordering flips
Rank by path rather than by score, and three things change:
- Isolated criticals sink. A high score on something unreachable stops consuming attention it never deserved.
- Cheap fixes rise. Cutting one edge (revoking a role, moving a secret) can sever an entire path. That is a smaller change than patching every node along it, and it removes the whole route.
- The argument gets concrete. "This role lets any instance in the account reach the customer database in two hops" is a sentence a platform team will act on. "There are 340 criticals" is not.
What CVSS does not do
None of this is a complaint about the standard. It was never meant to rank one company's cloud. But it helps to be exact about its limits.
- It does not score misconfigurations. CVSS rates published vulnerabilities. A public bucket or a wildcard role has no CVE and no CVSS score, even though those are where most cloud incidents start.
- It does not change with your environment. The same CVE scores the same on a laptop, a test box and the payment API.
- It does not measure likelihood. A 9.8 with no known exploit and a 7.5 being used in active campaigns are not ordered correctly by CVSS. That is what EPSS and the KEV catalogue are for.
- It does not chain. Two medium flaws that combine into full compromise are still two mediums.
Attack path vs CVSS score
| Aspect | CVSS score | Attack path |
|---|---|---|
| Unit of analysis | One vulnerability | A chain of hops from an entry point to a target |
| Who computes it | The advisory publisher, once | A tool that models your own environment, on every scan |
| Knows your network | No | Yes, through routes, security groups and load balancers |
| Knows your identities | No | Yes, through roles, policies and trust relationships |
| Covers misconfigurations | No, only published vulnerabilities | Yes, a misconfiguration is often the key hop |
| Output | A number from 0.0 to 10.0 | An ordered route, with the cheapest place to cut it |
| Best for | Describing a flaw consistently across vendors | Deciding what to fix first in your own estate |
Common misconceptions
"A 10.0 always comes first." Only if something can reach it. Otherwise it is a scheduled patch, not an incident.
"Attack path analysis replaces vulnerability scanning." It consumes scanner output. Without knowing which software is vulnerable, the path has no entry points to start from.
"An attack path needs a CVE somewhere." Many real paths contain none. A public endpoint, a leaked key and a wildcard role are enough.
Where CVSS still belongs
Once you know a result sits on a reachable path, severity tells you how bad that hop is if it is taken. It also remains the common language for describing a flaw across vendors and advisories. It is an input to prioritisation. When two results sit on equally dangerous paths, the higher CVSS score is a fair way to break the tie. It was never designed to be the whole of it.
Point-in-time scanners tend to sort by exactly this number, which is one reason their queues feel noisy. We set out the difference in Secorvia vs point-in-time scanners.
FAQ
Is CVSS useless for cloud security?
No. It is a consistent way to describe how severe a flaw is, and it belongs in any ranking. It just cannot be the only input, because it knows nothing about reachability or what sits behind the vulnerable asset.
Does CVSS v4 fix the environment problem?
Partly, on paper. CVSS v4.0 has Environmental metrics that let you adjust a score for your context, but they have to be filled in for each asset, and very few teams do that at scale. Most tools still show the base score.
What is a good replacement for sorting by CVSS?
Sort by whether the result sits on a reachable path to something sensitive, then by exploitation evidence such as KEV and EPSS, then by CVSS. Severity breaks ties rather than setting the order.
Do misconfigurations have CVSS scores?
No. CVSS applies to published vulnerabilities with a CVE. A public bucket or a wildcard IAM policy has no CVSS score, which is why a queue built on CVSS alone tends to hide them.
How many hops does a typical cloud attack path have?
Often three to five: an exposed entry point, one or two identity hops, and a data store. Identity hops are the ones most tools miss, because no single permission looks wrong on its own.
Secorvia ranks results by the attack paths they sit on rather than by CVSS alone.