What is an attack path in cloud security?

An attack path is an ordered chain of real relationships in your environment that leads from a point an attacker can reach to something worth taking. Each step uses access the previous step granted. In cloud, the steps are usually an exposed service, one or two identity hops, and a data store at the end.

The word "real" carries the weight. An attack path is not a threat model drawn on a whiteboard. Every hop corresponds to a setting that exists in your account today: a security group rule, a trust policy, a key in an environment variable. Change the setting and that hop disappears.

The parts of an attack path

Every path has the same three parts, whatever the cloud.

ENTRY POINT

Somewhere an outsider can act first. An internet-facing load balancer, a public bucket that accepts writes, an exposed management port, a leaked access key. It also includes trust that admits outsiders by design, such as a CI system allowed to assume a role.

HOPS

Each move from one resource to the next. A host that can reach a database over the network. An instance profile that can assume a role. A function whose environment holds a password. A service account that can impersonate another.

TARGET

The thing that makes the path matter: customer data, production secrets, an administrative role, a payment system. A path that ends in a sandbox is a curiosity. One that ends in the customer table is an incident in waiting.

The kinds of hops

Hops fall into four families. Tools that model only one or two of them will miss most real paths.

• Network hops. Routes, security groups, peering and load balancers that let one resource talk to another.
• Identity hops. One principal becoming another: sts:AssumeRole in AWS, service account impersonation in GCP, managed identities in Azure. These are often the longest and least visible steps.
• Credential hops. Secrets stored where the previous hop can read them. Environment variables, user data scripts, parameter stores with broad read access, CI variables.
• Data access hops. Permission to read or write the target itself, such as s3:GetObject on a bucket or a database user with full rights.

A worked example

Here is a path that contains no CVE at all, which is more common than people expect.

1. A GitHub Actions role in AWS trusts the GitHub OIDC provider but has no condition on the repository. Any repository on GitHub can request a token and assume it. That is the entry point.
2. The role's policy allows sts:AssumeRole on a deployment role in the same account. That is an identity hop.
3. The deployment role can read every parameter in Systems Manager Parameter Store, including the production database password. That is a credential hop.
4. The database accepts connections from the subnet the deployment tooling runs in. That is a network hop.
5. The database holds customer records. That is the target.

No scanner looking at one resource at a time would rank any of these steps as critical on its own. The trust policy is valid JSON. The parameter read permission is normal for deployment. The database rule matches a documented subnet. The danger only shows up when you read them in order. The first step on its own is a well-known problem, covered in more detail in who can walk into your AWS account from outside.

How tools find attack paths

The method is the same everywhere, even if vendors name it differently. First, collect configuration from every connected account: resources, network rules, policies, trust relationships. Then turn it into a graph where resources are nodes and every possible hop is a directed edge. Mark the entry points (anything reachable from outside) and the targets (anything sensitive). Finally, search the graph for routes from entries to targets and rank them.

Ranking is where products differ. A sensible ranking weighs how open the entry point is and how sensitive the target is, and it prefers paths that one small change can break. Length matters less than people think. A two-hop path from the open internet into an admin role beats a six-hop path from one pinned branch into a log bucket.

The output that matters most is the cut point: the single edge whose removal breaks the most paths. Often it is one role or one trust statement, and fixing it does more than patching every host along the route.

What attack path analysis does not do

• It does not prove exploitability. A path shows that access exists. Whether an attacker can actually use the entry point (a working exploit, valid credentials) is a separate question.
• It only sees modelled edges. If the tool does not read trust from outside identity providers, SaaS integrations or a second cloud, paths through those simply do not appear.
• It does not watch live traffic. It is built from configuration. A path that an attacker is walking right now looks the same as one nobody has touched.
• It does not know your data without help. Targets are only as good as the tagging or classification behind them.
• It is not a penetration test. A tester tries the path and reports what worked. Analysis lists what could work, at a far larger scale and with less certainty per path.

Attack path vs attack surface vs attack vector vs blast radius

For the outward-looking measure in the last row, see how blast radius is measured. For why a path beats a severity number when you decide what to fix first, see attack paths vs CVSS.

Common misconceptions

"Attack paths are only for large enterprises." A single AWS account with one CI role is enough to have a complete path.

"Longer paths are more dangerous." Usually the opposite. Short paths from wide-open entry points are the ones attackers use.

"If every resource passes its checks, there are no paths." Paths are built from settings that pass their checks individually. That is the whole reason they need their own analysis.

"Attack path analysis belongs to one vendor." Attack graphs are older than any current cloud product. BloodHound made them familiar for Active Directory in 2016, and most CNAPP products and several open-source tools build them for cloud now. They differ in which edges they model and how they rank. Our Secorvia and Wiz comparison covers that in detail.

FAQ

What is the difference between an attack path and an attack vector?

An attack vector is the method used at one point, such as exploiting a public API. An attack path is the whole route, from that first point through every hop to the asset the attacker wants.

Do attack paths always start with a vulnerability?

No. Many cloud paths contain no CVE at all. A public endpoint, an over-broad trust policy and a readable secret are enough to make a complete path.

How do I break an attack path?

Remove one hop. The cheapest is usually an identity hop, such as narrowing a trust policy or scoping an sts:AssumeRole statement to one role. Cutting one edge breaks every path that runs through it.

Are attack paths the same as MITRE ATT&CK techniques?

They are related. ATT&CK catalogues the techniques attackers use at each stage. An attack path is a specific sequence in your environment, and each hop can be labelled with the ATT&CK technique it corresponds to.

Can an attack path cross from one cloud to another?

Yes. A role in AWS can be trusted by a workload identity pool in GCP, which carries access across the boundary. Tools that scan each cloud separately will not see the full path.

Secorvia builds these paths across AWS, Azure, GCP and DigitalOcean on its Starter plan and above.