Infrastructure-as-code does not declare data stores with public network exposure

A database reachable from the open internet is the single most catastrophic misconfiguration class in cloud history: the Moltbook exposure Wiz Research documented in 2026 and the recurring MongoDB and Elasticsearch ransom sweeps (tens of thousands of open instances wiped and held for bitcoin) all started with exactly this, a data store bound to 0.0.0.0/0 instead of a private subnet. This check evidences SOC 2 CC6.6, protection against threats from outside system boundaries: an auditor will ask how you restrict network access to systems holding customer data, and your committed IaC is the artifact that answers. AI coding tools fail here reliably because generated Terraform and docker-compose examples default to publicly_accessible = true and 0.0.0.0:5432:5432 so the demo "just works", and nobody revisits the setting before production. The check reads only what is declared in the repo; it makes no claim about live cloud state.

In Terraform, set publicly_accessible = false on every aws_db_instance / aws_rds_cluster and replace any security-group ingress rule granting 0.0.0.0/0 (or ::/0) on database ports with the application security group id or a VPC CIDR:

ingress {
  from_port       = 5432
  to_port         = 5432
  protocol        = "tcp"
  security_groups = [aws_security_group.app.id]
}

For GCP Cloud SQL, remove any authorized_networks entry of 0.0.0.0/0 and use private IP or the Cloud SQL Auth Proxy. In production docker-compose files, drop the host port mapping entirely or bind to loopback (127.0.0.1:5432:5432); containers on the same compose network reach the database by service name without any published port.