Pen Testing Cloud Configurations With Infrastructure-as-Code Access

Cloud environments broke the assumptions that traditional penetration testing was built on. The old model made sense for static infrastructure: defined network perimeters, exposed ports, fixed IP ranges, known hosts. You could map the surface from outside and call it a fair representation of what an attacker would see. Cloud infrastructure doesn't work that way. Infrastructure changes daily through automated deployments and dynamic scaling. Identities, APIs, and machine-to-machine communications have displaced exposed ports as the primary attack surface. Serverless functions, managed services, and federated identity systems don't appear in external scans at all. The consequence is straightforward and underappreciated: a blackbox scan of a cloud environment misses most of what a real attacker would actually exploit. It sees endpoints. It doesn't see the IAM roles, service configurations, and provisioning logic that control what those endpoints can do. The attacker's model has shifted too; lateral movement now means pivoting across identities and cloud service permissions, not traversing network segments. So if your cloud infrastructure is defined in code, what does it actually mean to test it properly?

What Infrastructure-as-Code Actually Controls, and Why That Matters for Security

Terraform and CloudFormation templates are the authoritative definition of cloud state. Not documentation of it. Not a representation of it. The definition. Those files specify IAM roles and their permission boundaries, security group rules and network ACLs, S3 bucket policies and encryption settings, VPC topology and subnet routing, CI/CD pipeline configurations, and the permissions those pipelines assume when they run. If it lives in the cloud environment, something in the IaC created it.

The security implication of that fact is underappreciated. Every deployment re-instantiates whatever is in the template. A flaw in the template is not an incident; it is a repeating condition. Consider the contrast: a manual change to a security group in the AWS console can be corrected in minutes. A security group rule that is misconfigured in the Terraform template gets redeployed on every subsequent apply, across every environment that template touches. The live misconfiguration is just the current symptom. The template is the disease.

IaC also encodes dependencies that are entirely invisible from outside the environment. Which Lambda function assumes which role. Which role can invoke which downstream service. Which service has a data path to which S3 bucket. This relational structure, the wiring diagram of the cloud environment, exists as text in those template files. Reading them is not a convenience. It is a prerequisite to mapping the attack surface completely. You cannot reason about privilege escalation paths, lateral movement, or data exfiltration routes without understanding those dependencies, and you cannot understand those dependencies without access to the templates that define them.

The Specific Vulnerabilities That Only Appear When You Can Read the Templates

These aren't edge cases. They are the categories of vulnerability that matter most in cloud environments, and they are systematically invisible to external scanning.

Overly Permissive IAM

Wildcard actions or wildcard resources in IAM policies look innocuous in isolation. In context, they are often textbook privilege escalation paths. An external scan can tell you a role exists. IaC review tells you that role has both iam:PassRole and lambda:CreateFunction, which is a well-documented escalation chain: the holder can create a new Lambda function, attach a more privileged role to it via PassRole, and invoke it to execute actions their original role couldn't. That combination is only legible when you can read the full policy set. During a whitebox engagement, pulling all policies and roles via aws iam get-account-authorization-details and cross-referencing against the templates gives you the complete picture.

Hardcoded Secrets in IaC State and Templates

Terraform state files frequently contain plaintext values for secrets passed as input variables: database passwords, API keys, service account credentials. These don't surface in any runtime scan. They live in .tfstate files and in version control history, sometimes for years. Hardcoded secrets in Terraform state, repositories, and CI/CD environment variables represent one of the leading cloud breach vectors for exactly this reason: they're not misconfigurations in the traditional sense, they're artifacts of how infrastructure gets built, and they persist invisibly.

Trust Boundary Misconfigurations

S3 bucket policies, cross-account role trust relationships, and resource-based policies that grant access to a wildcard principal are invisible to external scanning. A bucket that appears private from the outside carries a resource policy granting read access to any authenticated account in the provider's ecosystem, not just yours. That condition exists only in the template. You cannot observe it from outside.

CI/CD Pipeline Permissions

Deployment pipelines frequently assume highly privileged roles to provision infrastructure; they need to in order to do their job. But if the pipeline itself can be influenced, through a pull request to a Terraform module, for instance, that privilege becomes reachable to anyone who can influence what gets merged. This entire attack path is invisible to blackbox testing. It doesn't live in the deployed application. It lives in the pipeline configuration and the IAM roles it assumes, both of which are defined in the IaC.

SSRF to Cloud Metadata

Server-side request forgery vulnerabilities in application code, paired with overly permissive instance profiles, create credential exfiltration paths via the cloud metadata endpoint. Identifying the actual risk requires seeing both the application code and the IAM role attached to the instance. Neither alone tells the complete story. The SSRF is an application finding; the instance profile is an IaC finding. Together, they constitute an end-to-end path to credential theft and privilege escalation.

The unifying point across all of these is that they are chained attack paths, not isolated findings. IaC access lets the tester reason about the chain. Without it, you're looking at individual nodes and hoping the picture assembles itself.

Why the Statistic About Human Error Is the Wrong Frame

Research consistently attributes the large majority of cloud misconfigurations to human error, with some analyses putting that figure at around 82% in recent years. The standard response to a number like that is predictable: better training, more thorough checklists, stronger guardrails, organizational culture change. Treat it as a people problem. Invest in people solutions.

That framing is wrong, and understanding why it's wrong changes what you think remediation requires.

When infrastructure is defined in code that is version-controlled and repeatedly deployed, human error becomes codified error. The mistake is made once. It then replicates automatically on every apply, across every environment the template serves. The human who made the error may have left the organization. The error remains, quietly re-instantiated every time the pipeline runs.

This changes what remediation actually means. Fixing a runtime misconfiguration means correcting the live resource. Fixing an IaC misconfiguration means correcting the template and then remediating every environment it has already been deployed to. These are categorically different interventions with different stakeholders, different timelines, and different verification requirements. Without IaC access, a pen tester can find the deployed symptom, but cannot determine whether it will recur. They are correcting a manifestation, not the source.

This is why IaC access changes the class of finding, not just the quantity of findings. A point-in-time finding tells you what exists now. A finding traced to the template tells you about a persistent, self-replicating condition. Those are not the same thing. Reporting them equivalently misleads the remediation effort.

What a Whitebox Cloud Pen Test Actually Does With IaC Access

The starting point for a genuine whitebox cloud engagement is repository access to the Terraform or CloudFormation templates, combined with read-only cloud credentials for live environment corroboration. Both matter. The templates show intent; the live environment shows reality.

Attack Surface Mapping From Templates

The engagement starts by enumerating all IAM roles, their trust policies, and their attached permission sets. From there, you map data flows: which services write to which buckets, which functions can invoke which APIs, which roles can assume other roles. You identify all network egress paths, including VPC endpoints and NAT configurations. This builds the internal map of the environment, not the external perimeter, but the actual wiring.

Privilege Escalation Path Analysis

With the full permission set enumerated, the analysis turns to combinations. No single permission is necessarily alarming. Combinations are. The common chains are well-documented: iam:PassRole plus ec2:RunInstances; lambda:CreateFunction plus iam:PassRole; sts:AssumeRole chains across accounts. The analysis is looking for places where the permissions granted to one principal, when combined with permissions granted to another principal that the first can reach, produce a path to capabilities neither was explicitly intended to have.

Cross-Referencing Templates Against Live State

The IaC template shows the intended configuration. The live environment shows what actually got deployed. Drift between the two is itself a finding. It means someone made a manual change outside the IaC workflow, which is simultaneously a security gap and a governance gap: something exists in the live environment that isn't tracked in version control, which means it won't be reviewed, it won't be tested, and it will survive indefinitely.

Chaining Findings Into Exploitable Paths

Every finding should be proven with a working exploit, not flagged as a theoretical risk based on policy text. "This role can be abused" and "we assumed this role and reached your production database" are not equivalent findings. The first is a scanner output. The second is a pen test result. The difference matters for remediation prioritization, for organizational buy-in, and, as discussed shortly, for audit defensibility.

It's worth distinguishing this work from what static IaC scanning tools like Checkov, tfsec, or Terrascan do. Those tools provide genuine value as CI/CD gatekeeping mechanisms. They run pattern-matching against templates before deployment, flagging known-bad configurations. But they don't reason about permission chains, business context, or chained attack paths. They cannot apply adversarial judgment to what a configuration enables in context. A skilled tester with IaC access does what those tools cannot, which is why the two are complements, not substitutes.

How IaC-Informed Findings Hold Up Differently in Compliance Reviews

Auditors for SOC 2, HIPAA, and ISO 27001 have become meaningfully more sophisticated about what a pen test report should actually contain.

SOC 2 Monitoring Activities criteria expect evidence that controls were tested, not merely listed. ISO 27001 Clause 7.2 requires documented tester competence, with traceability from findings to corrective actions addressed under Clause 10.1. The proposed 2025 HIPAA rule updates are expected to mandate annual penetration testing for all covered entities and business associates, raising the threshold for what constitutes a qualifying engagement.

In that environment, a finding backed by a working exploit carries a different weight than a scanner flag. "We assumed this role, accessed this bucket, and exfiltrated this class of data" is categorically more defensible in an audit than "IAM policy contains wildcard action." The first demonstrates that the control failed. The second demonstrates that a tool ran.

IaC-level findings also establish persistence in a way that purely runtime findings cannot. Showing an auditor that a misconfiguration is codified in the template makes a stronger case for why the corrective action must include template remediation, not just a live-environment patch. Without that trace, the auditor's reasonable question, "how do you know this won't recur?", has no satisfying answer.

For findings not immediately remediated, both SOC 2 and ISO 27001 require documented management acceptance of residual risk. An IaC finding with a clear reproduction path makes that documentation defensible. You can describe exactly what the condition is, exactly how it would be exploited, and exactly what would need to change to eliminate it. That is useful documentation. A risk score derived from automated policy analysis is not.

The audit-readiness and the genuine security finding converge here. A pen test that traces a vulnerability to its source in the IaC satisfies the auditor and gives the engineering team something actually actionable.

What to Look for When Evaluating Whether a Pen Test Will Actually Cover Your Cloud IaC

The diagnostic question is direct: will your testers have access to the Terraform or CloudFormation templates, or are they testing from outside the environment? A firm that says external scanning is sufficient for cloud is telling you they will miss every vulnerability category described above. That's not an exaggeration. It's a description of what external scanning can and cannot see.

Ask specifically about IAM analysis methodology. Can they describe how they enumerate privilege escalation paths from policy documents? Do they reference the specific AWS APIs they use for IAM enumeration? If the answer is vague, the analysis will be vague.

Ask about CI/CD pipeline scope. Will the engagement include the deployment pipeline and the roles it assumes, or only the deployed application? If the pipeline is out of scope, an entire class of attack path is untested.

Watch for specific red flags. A proposal that emphasizes tool output, ScoutSuite, Prowler, cloud security posture management reports, without describing manual analysis of permission chains is describing an automated scan with a pen test label. No scoping questions about IaC tooling, repository access, or CI/CD architecture indicates the firm isn't planning to work at the layer where the most consequential vulnerabilities live. A sample report organized by resource type rather than by attack path shows you the tester is cataloguing configurations, not reasoning about what an adversary would do with them.

There is also a pricing signal worth naming plainly. A genuine whitebox cloud engagement that includes IaC review, IAM analysis, and chained exploit proof requires skilled professionals spending significant time in the environment. A quote at the low end of the market is almost certainly an automated posture scan with a pen test label applied at the point of sale.

The final verification criterion is simple. Confirm that findings will be proven with working exploits, not theoretical risk scores derived from policy text. The difference between "this role can be abused" and "we abused this role and reached your production database" is the difference between a scanner output and a penetration test. Insist on the latter.