IaC & Cloud Misconfiguration

Domain

Infrastructure & systems

ROOTVIEL support

Heuristic — Pattern/presence detection, without a provenance or proof oracle.

Analysis family

infra

CWE

CWE-1032, CWE-16

OWASP

A05:2021

A cloud misconfiguration is a security-relevant setting on a provisioned resource left in an insecure state: a storage bucket readable by anyone, a database or cache reachable from the public internet, a firewall or security group that allows 0.0.0.0/0 to a sensitive port, encryption-at-rest disabled, audit logging turned off, or public access blocks removed. When the configuration is expressed as infrastructure-as-code (IaC) — declarative templates that provision resources — the same insecure setting is applied every time the template runs, so one bad default becomes a fleet-wide exposure.

This is OWASP’s Security Misconfiguration realized in the cloud control plane. The defect is not a code bug in an application; it is the state of the infrastructure itself. Because that state is increasingly declared in version-controlled templates, the misconfiguration is both more consistent (it ships identically everywhere) and more reviewable (it is text you can read before it exists) than a hand-clicked console change.

This is the dominant class of cloud incident: data is exposed not because an attacker defeated a control, but because no control was in the attacker’s way. It appears wherever resources are provisioned — storage, databases, queues, networking, identity — and especially wherever a default favors openness or a template was copied without reviewing its security settings.

• ▸Object storage buckets made public (or left without a public-access block) to "make sharing easy".
• ▸Security groups / firewall rules opening databases, caches or management ports to 0.0.0.0/0.
• ▸Encryption-at-rest or in-transit left disabled, and audit/flow logging switched off.
• ▸IaC modules reused across environments carrying the same insecure default into every one.

Cloud security is configuration-driven: the provider enforces exactly the posture you declare, and "secure" and "open" are often one attribute apart. The useful model is that each resource has a set of security-relevant attributes — access policy, network reachability, encryption, logging — and a misconfiguration is any attribute set to a value weaker than the data it protects requires. Nothing is "exploited"; the resource simply does what its configuration says.

With IaC, those attributes are static text evaluated before deployment, which is what makes this class amenable to pattern detection: a template that declares a public ACL, a 0.0.0.0/0 ingress rule, or encryption disabled can be flagged by reading the template, no running resource required. The flip side is scale — a reused module propagates the same attribute everywhere — so a single reviewed line can be worth a hundred console audits.

Infrastructure-as-code (IaC)

Declarative templates (e.g. Terraform, CloudFormation) that provision cloud resources, so their configuration is version-controlled text reviewable before deployment.

Public access / 0.0.0.0/0

An access policy or network rule that allows the entire internet; appropriate for a public website, dangerous for storage of private data or a management port.

Secure default

A resource’s out-of-the-box security posture. A least-privilege default (private, encrypted, logged) prevents whole categories of this class.

Drift

Divergence between the declared IaC state and the live resource, often from a manual console change that reintroduces an insecure setting.

The root cause is a security-relevant setting left weaker than the protected data warrants — incorrect use of a security feature, or reliance on an insecure default — and, with IaC, the codification of that weak setting so it deploys repeatedly. The mistake is usually convenience (open now, lock down later) or ignorance of a default (not realizing a bucket or port is reachable), rather than a deliberate decision.

A structural contributor is the gap between who writes the template and who owns the risk: an engineer optimizing for "it works" may not see that a single attribute exposes customer data, and without a policy gate in the pipeline, nothing reconciles the two before deployment.

1. 1An IaC template (or a console action) provisions a resource with an open or insecure attribute — public bucket, 0.0.0.0/0 ingress, encryption off.
2. 2The resource is deployed, often across several environments, each inheriting the same setting.
3. 3An attacker, or an automated internet-wide scanner, discovers the resource — public buckets and open ports are continuously enumerated.
4. 4Because the attribute itself grants access, the attacker reads the data or reaches the service directly; there is no further exploit to perform.
5. 5They exfiltrate data, pivot through the reachable service, or use what they find (keys, configs) to escalate further into the account.

The defining feature is that steps 4–5 require no vulnerability beyond the configuration. The resource was doing exactly what it was told; the attacker merely accepted the invitation.

A synthetic, illustrative IaC fragment that creates a public, unencrypted storage bucket and a security group opening a database port to the entire internet.

synthetic Terraform-style HCL — do not deploy; illustrates the flaw
# UNSAFE: public bucket, no encryption, and a database open to the world.
resource "cloud_object_bucket" "reports" {
  name = "acme-reports"
  acl  = "public-read"          # anyone on the internet can read objects
  # no server-side encryption block
  # no public-access-block attached
}

resource "cloud_network_sg" "db" {
  name = "db-sg"
  ingress {
    protocol   = "tcp"
    from_port  = 5432
    to_port    = 5432
    cidr_blocks = ["0.0.0.0/0"]  # database reachable from anywhere
  }
}
# One template run exposes every object and the database port to the internet.

The hardened version keeps the bucket private with an explicit public-access block and encryption enabled, and scopes database ingress to a known internal CIDR instead of the whole internet. The secure posture is declared, not assumed.

synthetic Terraform-style HCL — secure defaults declared
# SAFER: private, encrypted storage and a tightly scoped network rule.
resource "cloud_object_bucket" "reports" {
  name = "acme-reports"
  acl  = "private"              # no public access

  server_side_encryption {
    enabled = true              # encryption at rest on
  }
}

resource "cloud_object_bucket_public_access_block" "reports" {
  bucket                  = cloud_object_bucket.reports.name
  block_public_acls       = true
  block_public_policy     = true
  restrict_public_buckets = true
}

resource "cloud_network_sg" "db" {
  name = "db-sg"
  ingress {
    protocol    = "tcp"
    from_port   = 5432
    to_port     = 5432
    cidr_blocks = ["10.20.0.0/16"]  # internal application subnet only
  }
}
# Access and reachability are now scoped to what the data requires.

• ▸Data breach: public storage exposes files, backups or secrets to anyone who finds the resource.
• ▸Direct service compromise: a database, cache or management port open to the internet is attacked continuously and often needs only weak credentials to fall.
• ▸Account escalation: keys, tokens or configs found in an exposed resource enable deeper movement into the cloud account.
• ▸Scale: an IaC default multiplies a single mistake across every environment and region it provisions.

Two complementary layers. Static IaC scanning reads the templates before deployment and flags insecure attributes — public ACLs, 0.0.0.0/0 ingress to sensitive ports, encryption or logging disabled — as a presence/pattern signal. Cloud posture scanning (CSPM-style) reads the live account and finds resources whose actual state is insecure, catching drift and console changes the IaC never saw. The static signal is high-value and low-noise for well-known patterns, but "this attribute is open" is a configuration signal, not a demonstration that sensitive data was actually exposed to a real attacker.

This entry is reference material. ROOTVIEL’s verified, execute-and-prove engine is built for AI/agentic and Web3 findings, where it composes and runs a candidate attack and a deterministic verifier settles the result. Cloud and IaC posture is outside that proven surface; ROOTVIEL does not operate a verified engine for infrastructure vulnerabilities.

Make the secure posture the default and enforce it in the pipeline, so an insecure attribute cannot ship silently.

• ▸Preventive: default resources to private, encrypted and logged; require an explicit, reviewed justification to open anything to the public.
• ▸Preventive: attach public-access blocks to storage and scope network ingress to specific internal CIDRs, never 0.0.0.0/0 for sensitive ports.
• ▸Preventive (policy-as-code): gate IaC in CI with policy checks that fail the build on public buckets, open management ports, or disabled encryption.
• ▸Detective: run continuous cloud posture scanning against the live account to catch drift and manual changes the templates never saw.
• ▸Corrective: when a misconfiguration is found, fix both the template and the already-deployed resource, and add a policy rule so the pattern cannot recur.

Verify against the live resource, not only the template. Confirm the bucket denies anonymous access, the database port is unreachable from outside the intended network, and encryption and logging are on. Confirm the pipeline policy actually fails a deliberately insecure test template. Re-check periodically to catch drift. State the result as "the configured posture matches the declared secure state and the pipeline gate holds".

• ▸Opening a resource "temporarily" to debug and never closing it.
• ▸Fixing the console but not the IaC, so the next deployment reintroduces the insecure setting.
• ▸Scoping ingress to 0.0.0.0/0 for a port that only internal systems need.
• ▸Assuming a private network makes authentication and encryption unnecessary.
• ▸Reading a clean IaC scan as full safety while live drift and unscanned resources go unchecked.

IaC and cloud misconfiguration is the provisioning-layer sibling of an exposed management service (the specific case of a sensitive service left reachable) and frequently ships an over-privileged IAM role or a privileged container as part of the same template. All three are facets of security misconfiguration and yield to the same policy-as-code discipline.