Auditing Infrastructure As Code Exposures

Auditing infrastructure-as-code exposures: what the definition would actually provision

Infrastructure-as-code is desired state, so the bug is not what a line says but what the resource becomes once variables resolve, modules compose, and account defaults apply. A bucket ACL that reads public may be overridden by an account block, and a security group open to the internet may sit in a private subnet nothing routes to. This audit reads the definition and asks one question per resource: once applied, does this provision a resource that violates its security baseline, least exposure, encryption on, least privilege, logging on, no plaintext secret. Everyone has the checklist; the work that matters is adjudicating the effective config and killing the finding that a different layer already neutralizes. Anchor on auditing what exists, not generating or refactoring it.

When to use

• You have Terraform, OpenTofu, CloudFormation, Bicep, or Pulumi definitions for infrastructure in scope.
• A resource block declares storage, a network rule, an identity or resource policy, encryption, or logging.
• You want to know which blocks would provision an insecure resource once applied, not just which lines look wrong.

Scope check

Audit only definitions for infrastructure you own or are authorized to assess, and never apply a definition or mutate a live account to test a finding, adjudicate on the resolved config, not by provisioning. If you can't name the authorization, stop.

The loop

1. Resolve the effective config first. For each resource, follow the variables, locals, modules, and any tfvars, parameter files, or workspace overrides that feed its arguments, and factor in account or region defaults (default encryption, a block-public-access setting, an org policy). The literal in the module is not what deploys; the resolved state is. Settle it before judging any field.

2. Check storage exposure. Look for a bucket or object ACL of public-read or public-read-write, a bucket or resource policy with a wildcard principal, or block-public-access disabled, then confirm no account-level block or explicit deny overrides it. Public storage is the effective policy, not the ACL.

3. Check network ingress. Look for a security-group or firewall rule allowing the whole internet (an all-addresses source) on a sensitive port (remote admin, database, cache, search), then check whether the resource is actually reachable: a public subnet with an internet route and a public address, versus a private subnet a deny rule or absent route isolates.

4. Check identity and resource policies. Look for a policy granting wildcard actions or resources, an admin-equivalent managed policy, or a wildcard principal on a resource policy, then check for a condition, a permissions boundary, or an organization control that caps the effective grant. A wildcard narrowed by a real condition is not the same finding as an open one.

5. Check encryption, logging, and plaintext secrets. Look for encryption switched off or a snapshot or machine image shared publicly, access or audit logging or versioning disabled where the resource needs it, and a hardcoded password, key, or token in a variable default, a sensitive value's default, or a connection string. For a secret, report only that it is present in the definition; hand its blast-radius to the secret-reachability skill.

6. Confirm and record. Confirm by showing the resolved config provisions the insecure resource and no other layer neutralizes it. Kill the lead if an account block or explicit deny overrides a public ACL, if the open rule attaches only to a resource with no internet path, if the absent encryption field still provisions encrypted under an account default, if a wildcard policy is capped by a condition or boundary or service-control policy, if the value comes from an apply-time override rather than the literal, if the resource is never instantiated (count zero, empty iteration, a disabled flag, an uncalled module), or if a hardcoded secret is a documented placeholder or resolved from a secret manager at apply. Record the block, the resolved state, and the baseline it violates.

Where infrastructure-as-code leaks

• The bug is the effective config, not the line. Variables, modules, and account defaults change what provisions; adjudicate the resolved state, or you report the source and miss the deploy.
• A public ACL under an account block is inert. Storage exposure is the effective policy after overrides and denies, not the permissive ACL read alone.
• An open rule with no route is not reachable. A whole-internet ingress on a private-subnet resource with no public address and no route exposes nothing; reachability is part of the finding.
• A wildcard with a real condition is a different finding. A source-address, org, tag, or boundary condition caps the grant; report the uncapped wildcard, not the constrained one.
• A never-instantiated resource provisions nothing. Count zero, an empty iteration, a disabled flag, or an uncalled module means the insecure block never deploys.

Worked example (a confirm and a kill)

Confirm. A security-group rule allows ingress from the whole internet on the database port; the group attaches to an instance with a public address in a public subnet routed to an internet gateway, and no deny rule intervenes. The resolved config exposes the database to the internet. Confirmed internet-open database ingress on a reachable instance, high rising to critical for a credential-store port, remediation = restrict the source to the application tier and remove the public address.

Kill. A bucket declares a public-read ACL, but the account enforces block-public-access with a deny-all-public policy that overrides the ACL, so the applied bucket is private. Killed, kill_reason = "the public ACL is overridden by an account block-public-access setting that denies all public access, so the effective bucket policy is private."

Rationalizations to reject

• "The ACL says public, so it is public." -> Not if an account block or a deny policy overrides it. Adjudicate the effective policy, not the ACL in isolation.
• "The rule is open to the whole internet." -> Is the resource reachable? An open rule on a private, unrouted resource with no public address exposes nothing.
• "The IAM policy has a wildcard action." -> Is it capped by a condition, boundary, or org policy? A constrained wildcard is a different, weaker finding than an open one.
• "Encryption is not set." -> Does the account default to encrypted? An absent field can still provision an encrypted resource; check the default before flagging.
• "There is a password in the variable default." -> Is it a documented placeholder, or resolved from a secret manager at apply? Only a real literal baked into the deploy is the finding.

Executing this in practice

You need the definition files, the variables, modules, and apply-time overrides that resolve each argument, the account and region defaults, and any org or boundary policy that caps a grant. For each resource, resolve the effective config and decide whether it provisions an insecure resource no other layer neutralizes. Reading the block tells you what it asks for; resolving the variables, defaults, and overrides tells you what it actually provisions.

Related

• auditing-kubernetes-workload-and-rbac-hardening - the sibling for the Kubernetes YAML plane; this skill owns cloud provider resources, that one owns RBAC subjects and workload security contexts.
• auditing-container-image-build-hardening - the sibling for the image build plane; a hardcoded secret or root default in a Dockerfile belongs there, cloud resource state belongs here.
• hunting-non-human-identity-and-secret-reachability - takes the blast-radius of a secret this skill finds present in a definition, and the runtime reach of an over-granted identity.
• FINDING-SCHEMA.md - source = the declared resource block, sink = the insecure provisioned resource, evidence = the resolved effective config that violates the baseline.