Attack paths vs. misconfigurations: why chained findings are your real cloud risk

A busy cloud estate carries hundreds of open posture findings at any given time. Security teams triage by severity, work through the Critical queue, and ship patches. Three months later, the finding count is roughly the same. The board asks why the environment is still at risk.

The answer is that severity scores do not tell you which findings actually lead to breaches. They tell you how bad an individual misconfiguration is in isolation. But attackers do not exploit individual misconfigurations in isolation — they chain them together.

The finding that causes a breach is rarely the most severe finding on your list. It is the one that connects to five other findings in a path that reaches your most critical assets.

What an attack path actually is

An attack path is a sequence of exploitation steps that an attacker could take to move from an initial foothold to a target resource. Each step in the path exploits a specific misconfiguration or vulnerability. No single step requires extraordinary attacker capability — each one is a logical consequence of the previous.

A typical AWS attack path might look like this:

1. A Lambda function is exposed to the internet via an API Gateway without authentication. An attacker sends a crafted request that triggers an SSRF vulnerability in the application code.
2. The SSRF reaches the EC2 Instance Metadata Service (IMDSv1) and retrieves temporary credentials for the Lambda execution role.
3. The Lambda execution role has iam:PassRole permission on a deployment role used by the CI/CD pipeline.
4. Using iam:PassRole, the attacker creates a new Lambda function and assigns the deployment role, giving them pipeline-level permissions.
5. The deployment role has s3:GetObject on the S3 bucket where customer PII exports are staged for the data warehouse ETL pipeline.

At step one, the attacker is an anonymous internet user. At step five, they are reading customer PII. None of the individual misconfigurations — IMDSv1 enabled, overly permissive execution role, unscoped PassRole — are rated Critical in isolation. Together, they form a breach.

Chained findings: when 2 + 2 = 10

Some findings, in combination, produce a risk far larger than the sum of their individual severity scores.

A concrete example: suppose you have an EC2 instance that is internet-facing (a High finding) running a web application with a known CVE in its web framework (a Medium finding). Neither finding is marked Critical. But the CVE provides remote code execution, and the internet-facing exposure means the instance can be reached directly. The combination is Critical — a direct RCE entry point with no network controls in between.

Add one more element: suppose the instance profile grants ec2:DescribeInstances and ssm:SendCommand across the entire account. Now the attacker who exploited the CVE can run commands on every EC2 instance in the account. Three Medium/High findings. One account-wide compromise.

Crown jewel path analysis

Not all attack paths matter equally. A path that reaches a development environment with synthetic test data is not the same as a path that reaches your production payment processor or customer data lake. Crown jewel path analysis focuses on the resources you care most about — your crown jewels — and on every path that leads to them.

In Onam, crown jewels are the resources a path can end at — data stores such as S3, RDS and DynamoDB, encryption keys, admin roles and similar high-value targets — and the data classification labels from data security posture (taken from names, tags and schema) raise the impact of paths that reach sensitive stores.

The result is a list of paths ranked by likelihood and impact, so the path to the customer data lake outranks the path to a test bucket.

How Onam implements attack path analysis

Onam's attack path engine is built on a property graph. Every cloud resource — EC2 instances, IAM roles, S3 buckets, Lambda functions, security groups, VPCs, subnets, load balancers — is represented as a node. Relationships between resources are represented as typed edges.

Edges are derived from posture, identity, network, data and threat-detection evidence — for example an identity that can assume a role, a federation from another cloud, a security group rule that lets one workload reach another, or a key that encrypts a store. Each edge is marked confirmed, blocked or a gap, and only confirmed edges are walked.

Attack path discovery runs a breadth-first search across this graph, starting from entry points — the internet, admin identities, other identities, CI/CD, third parties and other clouds — and walking to every reachable crown jewel. Each path is scored on:

• Likelihood, which starts from the entry point and decays with every hop — shorter paths score higher.
• Exploitability — a node with a high-EPSS vulnerability raises the path's likelihood.
• Impact of the target, raised by its data classification.
• Confirmed controls — a WAF in front of the target or MFA on the entry point lowers the score.

MITRE ATT&CK tagging on every path step

Each step in an attack path is tagged with the MITRE ATT&CK technique it represents. This does two things: it grounds the abstract graph traversal in threat intelligence that security teams and CISOs recognize, and it gives security teams and auditors a shared, published vocabulary for what each step of a path does.

A path step that exploits IMDSv1 to steal credentials is tagged T1552.005 (Unsecured Credentials: Cloud Instance Metadata API). A step that uses iam:PassRole for privilege escalation is tagged T1548.005. A step that exfiltrates data from S3 is tagged T1530.

This tagging means that when you present an attack path finding to an engineering team, you can say: "This is a five-step privilege escalation path from an internet-exposed Lambda to your production database, using T1078 to T1548 to T1530. Here are the three changes that break the path at step two."

What to fix first: breaking the chain vs. hardening the target

When you have an identified attack path, you have two remediation strategies. You can harden the target — make the crown jewel harder to access — or you can break the chain: remove a link in the path so the attacker cannot traverse it.

Breaking the chain is almost always the right answer. Hardening the target is valuable — encryption, access logging, strict IAM policies on the database itself — but it does not eliminate the path. If the chain is intact, a sufficiently motivated attacker will find a way to the end.

Finding the optimal break point means identifying the link that:

• Has the lowest remediation cost — a one-line IAM policy change beats a network re-architecture.
• Blocks the most paths simultaneously — a single overly permissive role may appear in a dozen paths.
• Has no compensating control already in place.

Onam's path analysis marks the choke point — the resource that appears in the most paths — and shows how many paths fixing it would block.

Making the case to engineering

The practical challenge in attack path remediation is not technical — it is organisational. A Medium severity finding does not motivate an engineering team to drop their sprint work. An attack path that demonstrates a five-step route from the internet to production customer data does.

Attack path visualisations exist precisely for this reason. When you can show an engineer an interactive graph where each node is a resource they recognise and each edge is a permission they can verify in the AWS console, the remediation priority becomes self-evident. You are not asking them to trust a risk score. You are showing them the exact sequence an attacker would follow.

This is why attack path analysis is not a CSPM feature — it is a communication tool. It translates the abstract language of cloud misconfiguration into the concrete language of "here is how you get breached, here is what to change."