Attack path analysis
Attack path analysis shows which of your cloud problems an attacker can actually chain together, and which of those chains ends somewhere that hurts. This page covers how it works, how paths are ranked, what to fix first, and where the method runs out.
What attack path analysis is
Attack path analysis is the practice of modelling a cloud environment as a graph of resources, permissions and network routes, then searching that graph for chains that lead from a place an attacker can reach to an asset worth taking. Each chain is a path, and the analysis ranks the paths by how easy they are to walk and how much it would cost you if someone did.
That is a different question from the one a scanner answers. A scanner asks what is wrong with each resource. Path analysis asks what is reachable from outside, through which steps, and to what. If you want the definition of a single path first, what an attack path is covers it. This page is about the practice.
Why a list of findings is not an attack path
Take three facts about one AWS account. None of them would fail a review on its own.
- An EC2 instance sits in a public subnet, and its security group accepts HTTPS from anywhere. It runs a web service, so that is the point.
- The instance has an instance profile whose role can read objects from S3. The service needs to fetch its configuration, so that is also the point.
- The role's permissions include a customer export bucket, because a nightly job once ran on this host and nobody removed the grant.
A scanner that looks at one resource at a time sees an internet-facing web server, a role with read access and a private bucket. Three ordinary rows, probably rated low or not rated at all. Now put them together. If anyone gets code running on that instance, through a bug in the application or a vulnerable dependency, the instance can ask the metadata service for the role's temporary credentials and use them to read the bucket. The AWS documentation describes this: credentials for the attached role are available to software on the instance through the instance metadata service, and the newer version of that service, IMDSv2, requires a session token that makes it harder to reach through a forwarded web request. The same pattern exists on other clouds, and the DigitalOcean metadata endpoint is a case where we found no documented equivalent of that token.
The chain is the finding. The three settings are only its links. A list sorted by severity will not show you the chain, because severity belongs to a single row and the danger here lives in the relationships between rows.
How a path is built
A path is assembled from four kinds of evidence. Leave one out and the graph still draws lines, but some of them are wrong.
Asset inventory. Everything starts with a list of what exists: instances, roles, buckets, functions, clusters, databases. This comes from read-only calls to each cloud provider's API, so it is configuration and metadata, not the contents of your data stores. An asset missing from the inventory is a node missing from the graph, and any path through it is invisible.
Network reachability. Which resources can talk to which. That means route tables, security group and firewall rules, load balancers, peering, and whether an address is public at all. The question is not whether a rule exists but whether there is a working route from the source to the destination on a given port. A security group that allows everything on a subnet with no route to the internet is a very different thing from the same group on a public one.
Identity and trust. Who can become whom. Which principals a role trusts, which roles a principal may assume, what each role may do and to which resources. These edges are often the longest in a path and the hardest for a person to follow, since the information is split across trust policies, permission policies and resource policies. CIEM is the discipline of reading them properly.
Known vulnerabilities. Installed packages matched against vulnerability databases, with CVSS, EPSS and the CISA Known Exploited Vulnerabilities catalogue alongside. A vulnerability matters to a path in a specific way: it is a plausible way to take the first step or to move from one host to the next, so it only counts where the network and identity edges let an attacker use it.
Entry points and targets. Two more decisions shape the result. An entry point is anything an outsider can act on first: an internet-facing service, a public bucket, an exposed management port, or a trust relationship that admits another account or a CI system. A target is whatever you would be sorry to lose: customer data, production secrets, an administrative role. Both lists are judgement calls. A path that ends in a sandbox account is a curiosity, and the same chain ending in a customer database is an incident waiting for a trigger.
With those four inputs the analysis builds a graph, picks entry points (things reachable from outside) and targets (things worth reaching), and searches for chains between them. In Secorvia the graph is its own step, separate from scanning, which is why the graph guide tells you to check when it was last built. A scan that found a new resource this morning does not change the paths until the graph is rebuilt. See exploring the security graph.
How paths get ranked, and why reachability beats raw CVSS
Once there are many paths, order matters more than discovery. A reasonable ranking weighs a handful of things: how exposed the entry point is, how many steps the chain takes, whether each step needs something exotic or just an existing permission, how valuable the target is, and whether any step relies on a flaw that attackers are known to use. In Secorvia, each ranked path shows its severity, score, target, stage, the number of steps and a breakpoint where one is shown. The formula behind the score is not published, so treat the order as a prompt to look, not a verdict.
Why not simply rank by CVSS? Because a CVSS score describes the flaw. It says nothing about your environment, and FIRST, the body that maintains CVSS, says in its user guide that CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk. A 9.8 on a host with no inbound route, no role and nothing sensitive within reach is a patching task for the next maintenance window. A 5.3 on a public service whose role can read your customer data is the thing an attacker can use today. Reachability is the missing context, and it is the context that decides which of the two matters.
Exploit signals sharpen this further. EPSS estimates how likely a vulnerability is to be exploited in the wild, and KEV lists the ones already known to be. Neither knows whether the vulnerable host is reachable. Used with a path, they tell you how likely the chain's weakest step is to be attempted. Used without one, they rank the entire estate by something that is only half the question. The longer version of this argument is in attack paths vs CVSS, and CVSS, EPSS and KEV explains what each score does and does not mean.
What to fix first when several paths overlap
Real environments rarely produce one clean path. They produce a dozen that share pieces. The same role sits on three of them. One public host feeds two targets. Fixing paths one at a time, in score order, can mean doing the same repair three times.
A better method is to look for the shared piece. Count how many ranked paths pass through each resource and each permission, and start with the piece that appears most often. Cutting a link that serves five paths beats patching a host that serves one. In the example above, the role grant on the export bucket is one edge. Removing it ends the path, whether or not the application ever gets patched. Patching the application closes one way in and leaves the grant in place for the next one.
When a shared resource turns up, ask what falls if it is lost. That is blast radius: the set of assets reachable from one starting point. A resource with a large blast radius and several inbound paths is where effort pays back fastest. Blast radius goes through how it is measured.
A workable order looks like this:
- Paths from the internet to a target you cannot afford to lose, with the fewest steps.
- Any hop shared by several paths, especially an identity permission, since it is usually cheaper to change than a host.
- Paths where a step depends on a vulnerability that is on the KEV list.
- Everything else, in score order.
After a change, rebuild the graph and analyse again. A fix you have not re-checked is a belief, not a result. The attack path guide describes that verification step.
What attack path analysis does not tell you
This is where most vendor pages go quiet, and it is the part worth reading twice.
A path is a possibility, not an event. It shows that a chain can be walked, given the access that exists today. It does not show that anyone has walked it, and it is not a detection. For that you need logs and runtime tooling.
It is only as complete as the data behind it. The graph holds what the read-only connection could see. If the credential cannot read some service, or a policy could not be resolved, the picture has a gap, and a missing edge looks identical to a missing risk. Secorvia's own guides say the same about an unresolved policy: it means the record needs more context, not that no permission exists.
It is a snapshot. Infrastructure changes by the hour. A path found on Monday may be gone by Tuesday, and a new one may have appeared that no analysis has seen yet.
It cannot see inside your applications. A broken authorisation check in your own code is not a configuration, so no graph built from configuration will contain it. Nor can a tool that reads only configuration and metadata tell what a bucket holds. Deciding which targets matter stays with you.
Policy evaluation is hard. Permission boundaries, organisation-level controls, resource policies and conditions all interact. Any tool's model of how they combine can be wrong at the edges, so treat a path as a lead to confirm, particularly before you remove a permission from a production role.
It does not replace a penetration test. A test finds what a person can actually do, including the creative steps no model anticipated. Path analysis is cheaper and continuous. The two answer different questions.
How to try it
Connect an account with a read-only credential, wait for the first scan to complete, build the graph, and choose Analyze on the attack path page. Nothing is installed for cloud posture scanning. The attack path guide walks through each screen, and the connection guide covers AWS, Azure, Google Cloud and DigitalOcean.
On the plans: the free plan includes vulnerability intelligence and infrastructure-as-code scanning against your own account, with no card. The security graph and attack paths begin on Starter, at $149 a month billed annually or $199 billed monthly, as listed on the pricing page. If your first question is only who outside your account can assume a role inside it, the free frontdoor command line tool answers that without an account.