Blast radius: measuring what falls with a single asset
Two resources can carry the same finding and differ by three orders of magnitude in what their compromise costs you.
Blast radius is the set of resources an attacker can reach after they gain control of one asset in your environment. It is found by walking outward through permissions and network routes from that asset. It measures what a single compromise would cost you, not how likely that compromise is.
So the question is not "what is this resource worth?" It is "what does holding it give me?" That distinction is the whole point. A build agent may hold nothing of value itself and still be the most dangerous box in the estate, because of what its credentials can reach.
How it is computed
Blast radius is a graph traversal. Model the environment as nodes (instances, roles, functions, buckets, databases, clusters) and directed edges (can assume, can invoke, can read, can reach over the network). Start at one node. Walk outward along the edges an attacker could actually traverse, and collect what you touch.
Two details decide whether the result is useful:
- Edges must be permission-aware and network-aware. "Instance A can reach database B" is only true if a route exists and something on A can authenticate to B. An edge that ignores either half produces a radius that is dramatic and wrong.
- Direction matters. Blast radius follows edges outward from the asset. Reachability (can anyone get here in the first place?) follows them inward. You need both, and conflating them overstates risk badly.
Identity edges deserve special care. In AWS, an instance profile that can call sts:AssumeRole on a second role extends the radius to everything that second role can do, and so on down the chain. Many of the longest radii in a real account are built almost entirely from these hops, with no network movement at all. That is why entitlement analysis and blast radius end up reading the same graph.
Why it changes the order of work
Consider two instances with the identical unpatched package:
- INSTANCE A
- Runs a static marketing site. Its instance profile allows read on one public asset bucket. Blast radius: one bucket that is already public.
- INSTANCE B
- Runs an internal job. Its instance profile can assume a deployment role with a wildcard policy on the account. Blast radius: every role that role can reach, and everything those roles can read, including the customer database.
A severity-sorted queue lists these side by side, because the vulnerability is identical. A queue that knows the blast radius puts B far above A, and it can say why in one line.
Reading it well
A raw count, "47 assets in blast radius", is a start. But it rewards breadth over consequence. What matters is the most sensitive thing in the set. Forty-seven development sandboxes are a smaller problem than one production database, so weight the radius by what it ends in, not by how many nodes it contains.
A few uses come up again and again:
- Ranking findings that look equal. The two instances above are the standard case.
- Finding chokepoints. One over-permissioned role often appears in the radius of dozens of assets. Fixing it shrinks all of them at once, which is the most valuable single change most teams have available on any given day.
- Checking segmentation. If a sandbox instance's radius includes production, the boundary you believe exists does not.
- Sizing an incident. When a credential leaks, the first question responders ask is what it could touch. A precomputed radius answers that in seconds instead of an afternoon of reading policies.
What blast radius does not do
It is easy to treat a large radius as an emergency. Often it is not, and the reasons are worth spelling out.
It does not tell you whether anyone can get in. An asset with an enormous radius and no path in from anywhere is a latent problem, not an active one. Worth fixing. Not worth waking anyone up for. Pair blast radius with reachability or you will have swapped one misleading sort order for another.
It does not know what your data is worth. The graph can tell you that a role reaches a bucket. It cannot tell you whether that bucket holds payroll exports or yesterday's build logs unless someone has tagged or classified it. Unlabelled data makes every radius look the same size.
It only covers what was modelled. Trust that enters the account from outside, such as an OIDC provider that lets a CI system assume a role, is frequently left off the graph entirely. So are SaaS integrations holding long-lived keys. A radius computed without those edges is accurate about the inside of the account and silent about the doors into it. We wrote about that gap in who can walk into your AWS account from outside.
It is a snapshot of permissions. The radius reflects policies as of the last scan. A policy widened at 3pm is not in a radius computed at noon.
It ignores your detection controls. A path that would trip an alert on the first hop is still a path in the graph. Blast radius measures exposure, not how fast you would notice.
Blast radius vs attack path vs severity
These three get mixed up in reports and in vendor pages. They answer different questions, and a good queue uses all three.
| Question | Blast radius | Attack path | Severity score |
|---|---|---|---|
| What it answers | What an attacker gets after taking this one asset | How an attacker gets from an entry point to a target, hop by hop | How bad a single flaw is in the abstract |
| Direction | Outward from one asset | From an entry point inward to a target | No direction; it describes one finding |
| Built from | Your permissions and network routes | Your permissions, network routes and exposed entry points | The vulnerability or rule definition only |
| Changes when | A policy or route changes in your account | Any hop on the route changes | The advisory is rescored, which is rare |
| Best use | Ranking equal findings, finding chokepoints, sizing incidents | Deciding which single change breaks a breach route | Describing a flaw consistently across tools |
| Main blind spot | Says nothing about whether the asset is reachable | Only as complete as the edges you modelled | Knows nothing about your environment |
For the long version of the last column, see why a CVSS score cannot prioritise your cloud risk. For how the middle column is built step by step, see what an attack path is.
Common misconceptions
"A bigger radius is always worse." Size is a weak signal. A radius of three that ends in the customer database is worse than a radius of three hundred sandbox objects.
"Blast radius is the same as lateral movement." Lateral movement is what an attacker does. Blast radius is the map of what they could do. One is an event, the other is a property of your configuration.
"If the radius is small, the finding can wait." Not if the asset is internet-facing and the small radius includes a secret. Reachability and radius have to be read together.
"Only compute assets have a blast radius." Roles, service accounts, CI tokens and access keys all have one, and theirs are usually the largest.
If you are weighing tools on how they present this, the Secorvia comparison pages lay out where each vendor's graph stops.
FAQ
How is blast radius different from attack surface?
Attack surface is everything an outsider can touch from the internet. Blast radius starts after the attacker is already holding one asset and asks what that asset can reach next. One looks inward from outside, the other looks outward from a foothold.
Does blast radius include identity permissions or only network access?
Both, and in cloud the identity half is usually larger. A role that can assume another role extends the radius without any network hop at all. A tool that only follows network routes will report radii that are far too small.
How often should blast radius be recalculated?
Whenever permissions or routes change, which in an active account is daily. A radius computed from last month's policies describes an account that no longer exists.
Can I reduce blast radius without re-architecting?
Usually yes. Removing one wildcard policy, scoping a sts:AssumeRole statement to a single role ARN, or moving a secret out of environment variables can each cut a radius sharply. Look for the chokepoint roles that appear in many radii and start there.
Is blast radius useful during an incident?
Very. When a key or token leaks, the radius of that credential is the list of things responders need to check first. Having it precomputed turns hours of policy reading into a short list.
Secorvia computes blast radius from any node in its security graph across AWS, Azure, GCP and DigitalOcean.