a3thinker
Get in touch

Articles

AWS now traces the IAM part of my attack paths

In July, AWS Security Hub started tracing privilege escalation chains from exposed resources. Within an AWS account, this is the question my engine was designed to answer, and AWS partially addresses this question with policy logic that my engine doesn't read. Here's what AWS does better, what its documentation doesn't describe, and where I've moved my work.

12 October 2026 路 7 min read 路 PerspectiveGraph 1.29.0 路 AWS Security Hub

In short

  • Security Hub now traces what an attacker could access from an exposed resource via IAM permissions, evaluated against the organization's guardrails. My engine doesn't evaluate these guardrails.
  • Its documentation doesn't describe three things: permissions inside a Kubernetes cluster, the code from which a workload was created, and the question "does this change open a path?"
  • So the work has been moved there. These are statements about documentation, dated October 2026, not a direct comparison.

What AWS shipped

On 6 July 2026 AWS added impact analysis to Security Hub's exposure findings. An exposure finding starts with a resource that has a problem: it's reachable from the internet, runs a vulnerable package, or is misconfigured. It combines signals from AWS services: Inspector for vulnerabilities, GuardDuty for threats, Macie for sensitive data, and Security Hub's configuration checks. Impact analysis then asks what an attacker who gained control of that resource could achieve. It calculates the effective permissions of the IAM identities associated with the resource and traces privilege escalation chains to other resources in the account. It displays each chain with the permission associated with each step and factors the result into the finding's severity level. The next day, AWS announced that Security Hub monitors Azure resources too.

This is virtually identical to what PerspectiveGraph answers within an AWS account: the internet reaches an instance, the instance holds a role, and the role can self-assign administrator privileges. Now the platform natively traces this path for every customer who activates it.

Where it is better than my engine

The permissions it evaluates are the real ones. AWS calls them effective permissions: a principal's own policies, along with the policies on the resources it would have access to, and the service and resource control policies applied by an AWS Organization. My engine's policy reader doesn't evaluate service control policies or condition keys. This is a deliberate and documented choice. It's also why I already ask the AWS policy evaluator to verify the engine's IAM claims: that is how it found the false positive I wrote about. AWS defines the meaning of an IAM policy, and any reimplementation of those semantics trails the original.

Its inputs are already there. Inspector's reachability analysis, GuardDuty's threat findings and Macie's sensitive-data classification feed it with no export step, and IAM Access Analyzer's unused permissions appear beside each finding. Its Azure coverage is live; mine is tested on sample data.

In short: if your infrastructure is AWS and you're wondering how far a compromised instance or function could escalate within your account, Security Hub now provides the answer. I'd rather specify it here than leave it up to the reader to figure it out.

What its documentation does not describe

I've read the pages defining the feature: the trait types, the effective permissions and the attack path graph. Three things I was looking for aren't present. The lack of information in the documentation doesn't mean the product lacks them, so consider the following to be what I couldn't find as of October 2026.

Permissions inside a Kubernetes cluster. An EKS cluster appears as a resource: it can be reachable, vulnerable, or have unused permissions. But impact is calculated based on the permissions of IAM principals, and Kubernetes' permission system, RBAC, is not among the listed inputs. Under RBAC, a service account that can create pods or read secrets can often become cluster administrator. Connections between the two systems are also not included:

  • a service account assuming an IAM role (IRSA, Pod Identity);
  • an IAM role admitted into the cluster with cluster rights (the aws-auth map, access entries);
  • a pod escaping its container onto the node, and with it the node's role.

Real attacks on EKS often occur precisely at these points, between the two systems.

The code that built the workload. Since June 2025 Inspector can scan repositories and report its findings on pull requests. However, the documented input for the vulnerability trait concerns package vulnerabilities. I've found nothing that links a weakness in a repository to the image built from it and, subsequently, to the workload running that image.

A question asked of a change. Exposure findings describe what's deployed. Inspector's pull-request findings describe what is wrong inside a diff. I haven't found either described as answering whether a commit opens a path from the internet to sensitive data that didn't exist before.

Where the work moved

The IAM escalation reader remains. It's necessary for paths and is the connection point to other domains. But it's no longer the central point. Release 1.29.0 moves the work where those documented inputs end:

  • Cluster and account are joined. Service accounts gain access to their IAM roles via IRSA or Pod Identity. IAM roles gain access to their assigned cluster rights via aws-auth or access entries. A pod that can escape gains access to its node machine and that machine's role. A path can now start from a Kubernetes ingress and end as account administrator, or start from an IAM role and end as a cluster administrator.
  • CI is an entry point. An IAM role that trusts GitHub Actions without restricting which repositories can assume it is open to any workflow on GitHub. The engine now starts paths from there.

Part of the same release focuses on catching up rather than standing apart, and I prefer to clearly define this rather than pass it off as something more. Exposure is now determined port by port and per address family, and Security Hub already analyzes security groups and network ACLs. S3 buckets, Lambda functions and ECS services were already resources in its exposure findings. Without them, cross-domain paths would be starting from the wrong premises. Releases 1.30 and 1.31, which read load balancers and API Gateway routes, are the same type of work: filling in the AWS side, not standing apart from it.

Update, 1.34.0. The question asked of a change is now asked before deployment. The merge gate reads a Terraform plan and rejects the pull request whose security group rule, policy attachment or bucket policy opens a path. A test environment then applies the evaluated plans to a real account and asks the internet and AWS's policy simulator what happened. On the first run, all six checks passed.

The case for the engine now rests on four things, each of which can be checked:

  • A single path between domains: code, image, workload, cluster, and account in a single chain, built from scanners already in use by the team.
  • Probabilities that can be wrong. Security Hub rates an exposure Critical, High, Medium or Low from how easy it is to discover and to exploit, how likely an exploit is, how widely it is known, and its impact. A label like that orders a queue, but it makes no claim that can be graded afterward. A probability does: if the engine says 70% across a hundred paths and attackers get through twenty, the engine was wrong. It grades its own probabilities against the outcomes you record, and it says "not enough outcomes yet" until there are enough. It has not been calibrated against field data, and the README says so before anyone asks.
  • The merge gate. A commit status that turns red when a change opens a path from the internet to a sensitive resource and blocks the merge once it becomes a required check.
  • Open source and self-hosted. The logic is readable, the graph stays where it runs, and when the engine disagrees with AWS you can understand why.

What this does not prove

  • I compared documentation, not behavior. I have not yet run Security Hub's impact analysis and the engine in parallel on the same account. This will be the next measurement and may affect some parts of this article.
  • AWS releases updates quickly. The three gaps mentioned above are dated October 2026, and each could be addressed with a single announcement.
  • The new paths between clusters and accounts are being tested on sample data, not yet on a real EKS cluster.
  • While I was writing this, a lab test on a real AWS account subjected the new S3 and Lambda readers to AWS's judgment: three bucket policies that AWS defines as public were read as private, and a function URL that AWS denies to an external user was read as public. All four issues were fixed in version 1.29.1, and the lab test now fails if there is a discrepancy.
  • A difference is not demand. Whether teams need a cross-domain path to the point of using another tool is a question no test answers.

What I take from it

When a platform releases part of what you've built, read its documentation as carefully as you did your own code. Clearly indicate where it's better. Then, insert your work where the description stops and date the claim: sooner or later it will expire.

All articlesBack to the CV