Ask a traditional pentest firm what they cover and you will typically hear application layer, APIs, authentication mechanisms, and in some cases network-level exposure. Ask whether they cover your IAM role assignments, your S3 bucket policies, your VPC security group rules, or your EC2 instance metadata service configuration, and the answer is usually a conversation about scope expansion, additional fees, and cloud-specific expertise that many firms genuinely do not have.
This is a significant gap. In post-incident analyses of cloud breaches, the most common lateral movement paths are not application layer exploits. They are misconfigured cloud control plane resources: overpermissioned service account roles, publicly accessible storage buckets, instance metadata service endpoints reachable from application code with SSRF vulnerabilities, and trust relationships between services that were configured once and never reviewed again.
Why Traditional Pentests Skip the Cloud Control Plane
The practical reason is historical. Traditional application penetration testing evolved when "the infrastructure" meant physical servers and network gear managed by an operations team. The pentest was scoped to the application and its exposed network surface. The underlying infrastructure was assumed to be managed separately, hardened separately, and not part of the application security boundary.
In a cloud-native architecture, that assumption breaks completely. The IAM role assigned to your application's EC2 instance or Lambda function is part of your application's security posture. If that role can call sts:AssumeRole on a privileged role, or secretsmanager:GetSecretValue on production secrets, or s3:GetObject on a bucket containing customer data, those permissions are as much a part of your attack surface as any endpoint in your API.
The operational reality of cloud also means that misconfiguration accumulates over time in ways that on-premises infrastructure does not. Cloud resources are created quickly (an engineer can spin up a new S3 bucket in 30 seconds), configurations drift as requirements change, and cleanup is inconsistent. A bucket that was created for a specific feature, granted public access during development for convenience, and then forgotten about is a realistic scenario, not a contrived one.
The IAM Privilege Escalation Problem
IAM misconfiguration is the category that most consistently shows up as the enabling layer in cloud breaches. The core problem is that IAM policies are complex, additive, and frequently configured by people who do not have a clear mental model of what combination of permissions enables what actions.
Consider what privilege escalation looks like in AWS. A service role has iam:PassRole and ec2:RunInstances. Those seem like ordinary operational permissions. But the combination allows the service to launch an EC2 instance with an arbitrarily specified IAM role, including a role with broader permissions than the service itself has. From an application compromise, an attacker can pivot to control a new instance running with privileged permissions.
There are dozens of similar privilege escalation paths in AWS IAM, many of which are not obvious from looking at individual permissions in isolation. Enumerating them requires understanding the combinations: lambda:CreateFunction plus lambda:InvokeFunction, iam:UpdateAssumeRolePolicy, glue:CreateDevEndpoint in combination with a permissive role. These are not theoretical attack paths. They are documented techniques used in real-world lateral movement.
A traditional application pentest does not look at any of this. Even an AWS-focused security review that checks for overly permissive policies using automated rules often misses the combinatorial privilege escalation paths because they require analyzing permission combinations, not individual permissions.
SSRF as the Cloud Misconfiguration Connector
Server-side request forgery vulnerabilities take on additional severity in cloud environments because of the EC2 Instance Metadata Service (IMDS). An SSRF that can reach internal network addresses can make requests to http://169.254.169.254/latest/meta-data/ on IMDSv1, retrieving the IAM role credentials attached to the instance. Those credentials can be used directly to call AWS APIs with the permissions of the instance role.
IMDSv1 is susceptible to SSRF because it does not require any session token or additional headers. A single SSRF request to the metadata endpoint retrieves temporary AWS credentials. If those credentials have meaningful permissions (and they often do because developers grant permissions generously to avoid debugging IAM access denied errors), the SSRF becomes a path to full cloud account access.
AWS has addressed this with IMDSv2, which requires a two-step process using a PUT request to get a session token before making metadata requests. IMDSv2 blocks SSRF-based metadata retrieval in most cases. But many older EC2 instances still run with IMDSv1 enabled, and configurations are not always updated when new instances are launched from existing AMIs. This is exactly the kind of configuration detail that a traditional application pentest does not check but that directly determines whether an SSRF finding is a medium-severity annoyance or a path to cloud account takeover.
Public Storage Buckets: The Long Tail
Publicly accessible S3 buckets (and equivalent storage in GCP and Azure) remain a persistent source of data exposure despite years of AWS making the default more secure and adding guardrails. The reason is that the guardrails apply to new buckets. Older buckets created before ACL restrictions were tightened sometimes retain permissive settings. Buckets created by third-party tools or IaC templates that had different defaults at the time of creation can be public without being obvious from the current AWS console defaults.
The risk is not always direct public exposure. Sometimes the issue is that a bucket that should be private is accessible to any authenticated AWS user (the principal * with no condition on AWS account). That means any AWS account can access the bucket, not just the public internet. In an environment where developers have personal AWS accounts, that ACL is not providing the isolation it appears to provide.
Systematically auditing bucket policies and ACLs across an account requires API access, not a web application test. It also requires doing it continuously, because new buckets are created regularly and policies get modified. A quarterly check finds what was misconfigured at the time of the check. Continuous monitoring finds what gets misconfigured between checks.
Connecting Cloud Misconfiguration to Application Layer Findings
The most actionable way to think about cloud misconfiguration is as the second link in exploit chains that start at the application layer. An application layer vulnerability (SSRF, deserialization, SQL injection to file write, RCE through a dependency) provides the initial foothold. The cloud misconfiguration determines what the attacker can do from that foothold.
This is why we built Strix to cover code, APIs, and cloud configuration simultaneously rather than treating them as separate scopes. An SSRF finding in isolation might be rated Medium severity. The same SSRF finding, when the system maps that the target application runs on an EC2 instance with an overpermissioned role and IMDSv1 enabled, is rated Critical. The severity change comes from the cloud configuration context, not from the application finding itself.
Traditional pentests that scope to the application layer and leave cloud configuration to a separate assessment cannot make this connection because they do not have visibility into both sides simultaneously. The combining step is where significant risk lives, and it is the combining step that is most commonly missed.
Getting Cloud Configuration Into Your Security Testing Scope
The practical path for most teams is to include cloud configuration assessment as a required component of any security engagement, not an optional add-on. Define the cloud account(s) as in-scope alongside the application, and require the security assessment to enumerate IAM privilege escalation paths, identify publicly accessible storage, and check IMDS configuration on compute resources.
For continuous monitoring, cloud security posture management (CSPM) tools provide automated rule-based checks. Those are useful as a compliance baseline but have the same limitation as CVSS scoring: they evaluate individual configurations against rules without connecting them to each other or to the application attack surface. Connecting cloud configuration findings to application-layer findings, and evaluating the combined chain, requires a unified view that most CSPM tools do not provide.