Open any cloud security scanner and you get the same artefact: a list, sorted by severity, criticals first. It looks like a to do list, so most teams treat it as one. You work down from the top, and a week later you have closed eleven criticals and your real exposure has not moved at all.
Here is why that happens.
A severity score describes the flaw, not your account
CVSS was built to rate a vulnerability in the abstract: how bad would this be, in the worst reasonable case, for anyone running this software anywhere. That is a genuinely useful number. It is also a different question from the one you need answered, which is how bad this is for you, in this account, today.
Two findings make the difference obvious.
The first is a critical remote code execution bug on a host sitting in a private subnet. No public address, nothing routing to it from outside, and the only machines that can reach it are locked down. The score says 9.8.
The second is a medium severity misconfiguration. A storage policy lets a role read a bucket, and that role happens to be attached to a container running behind your public API. The score says 5.3.
An attacker never sees your list. They look for a way in, and then they look at what that way in can touch. The medium is the one that matters, because it sits on a path that starts somewhere they can actually stand.
Attacks are chains. Scanners report links.
Every real incident I have read up on looks the same in outline. Something exposed gets used, that thing has an identity, the identity can reach more than anyone intended, and three unremarkable steps later someone is reading a database.
No single step in that chain looks alarming on its own. The exposed service is patched. The identity has permissions someone granted for a reason two years ago. The database is private. Each finding, considered alone, is a medium at worst. Together they are the whole breach.
This is the gap a severity sorted list cannot close, because it ranks items, and the risk lives in the relationships between them.
A different order, which you can do by hand
You do not need a product to start. You need to ask the questions in a different sequence.
Begin from the outside. Write down everything in your account that can be reached from the internet: load balancers, public buckets, API gateways, anything with a public address, and anything with a trust policy that lets an outside party assume into you.
For each one, find the identity it runs as. The role on the container, the service account on the function, the instance profile on the host.
Then follow that identity. What can it read, what can it write, and crucially, what else can it become. Role chaining is where short lists turn long.
Now re-rank your findings by whether they sit anywhere on those paths. Most will not. The few that do are your actual week of work.
The first time a team does this, the usual reaction is that the list got much shorter and much more uncomfortable.
Why I ended up building this
Doing it by hand works once. It does not survive a second account, or a change on Thursday that quietly puts a new route in place.
So I built Secorvia around that ordering: it connects read only to AWS, Azure, GCP or DigitalOcean, puts findings on one graph with the identity relationships that connect them, and ranks by what is reachable rather than by score. You can see it at https://www.secorvia.com.
But the tool is not the point of this post. The ordering is. If you take one thing from it, let it be this: before you fix the critical at the top, spend ten minutes finding out whether anything can reach it. Quite often nothing can, and the thing that can reach your data is sitting twelve rows down, coloured yellow.