Infrastructure as Code Security: What Terraform and CloudFormation Misconfigurations Look Like

Infrastructure as code (IaC) tools like Terraform and CloudFormation changed infrastructure provisioning by making it declarative, version-controlled, and repeatable. Those properties are significant improvements over manual configuration and click-through console provisioning. They also mean that a security misconfiguration in an IaC template can be committed to source control, reviewed and approved without security scrutiny, replicated across development, staging, and production environments, and deployed at the speed of a pipeline run. The same automation that makes IaC powerful makes misconfiguration at scale easy.

IaC security assessment is not a new concept, but it is still inconsistently practised. Many engineering teams have adopted IaC for infrastructure management without adding any security checks to the IaC development and review process. The result is infrastructure that is well-managed from an operational perspective but has accumulated security configuration debt that is not visible without a dedicated review. The specific misconfiguration patterns that appear most frequently are well-documented and systematically checkable, which makes IaC security scanning one of the higher-leverage additions to a DevSecOps programme.

Common Terraform Misconfiguration Patterns

In Terraform configurations, the most frequently identified findings relate to overly permissive network access controls. Security group rules that allow inbound access from any IP address to sensitive ports (such as database ports, administrative interfaces, or internal management APIs) appear regularly, often because they were set during initial development for convenience and never restricted. Storage resources configured for public access are another common finding: object storage buckets with public read or write access have been the source of significant data breach incidents across multiple cloud environments.

Encryption configuration misses are a consistent category. Managed database instances deployed without encryption at rest, storage volumes attached to compute instances without encryption enabled, and backup configurations that do not inherit the encryption settings of the primary resource all appear regularly in IaC reviews. Logging and monitoring configurations are also frequently absent or incomplete: resources deployed without audit logging enabled, or with logging directed to a destination that itself has inadequate access controls. These are not novel findings. They are the same classes of misconfiguration that appeared in manually configured environments, now systematically embedded in version-controlled templates.

Common CloudFormation Misconfiguration Patterns

CloudFormation templates share most of the same misconfiguration categories as Terraform, with some platform-specific additions. Identity and access management configurations in CloudFormation are a significant source of findings. IAM roles created with wildcard action permissions, policies that grant broad access to all resources of a service type rather than specific resources, and cross-account trust relationships with permissive conditions are all common. These findings are often the product of a "make it work first" approach during development where permissions are broadened to unblock progress and never subsequently restricted.

CloudFormation templates also frequently contain hardcoded values that should be parameterised or retrieved from a secrets management service at deploy time. Account IDs, endpoint URLs, and in some cases credentials or API keys embedded as literal strings in templates are findings that create both operational inflexibility and security risk. Parameters and dynamic references to secrets management services are the appropriate pattern, but they require slightly more effort to implement than hardcoded values, and the path of least resistance is not always the secure one.

Integrating IaC Security Scanning Into the Pipeline

Static analysis tools for IaC templates can run as part of the CI/CD pipeline and check templates against a rule set covering the most common misconfiguration categories before any infrastructure is provisioned. These tools read Terraform or CloudFormation files and report findings with references to the specific resource and attribute, making remediation straightforward. Running these checks in the pull request pipeline means findings are visible at code review time, before the template is merged and the infrastructure is provisioned.

The configuration of IaC scanning tools requires the same calibration as other pipeline security tools. Default rule sets may be too broad for a specific environment, generating noise from findings that are accepted risks or are mitigated by other controls. Suppression rules for accepted findings should be documented and reviewed periodically. The scan should cover not just the main Terraform or CloudFormation files but also reusable modules or nested stacks, which are a common location for misconfiguration that propagates to every environment that uses the module.

Policy as Code and Governance

Beyond reactive scanning of existing templates, mature IaC security programmes use policy-as-code tooling to define and enforce security standards for infrastructure configuration. Policy rules are defined in code, version-controlled alongside the infrastructure templates, and evaluated at deployment time so that non-compliant configurations cannot be applied to the environment regardless of what passes the pipeline scan. This adds an enforcement layer that accounts for IaC changes made outside the normal pipeline process.

If you are using IaC for infrastructure management and have not assessed the security posture of your templates, the accumulated misconfiguration debt is likely larger than it appears from an operational perspective. We can review your IaC configurations and help integrate systematic security scanning into your pipeline. Contact us at info@cyberlinx.com.au.