Infrastructure as Code Security: Scanning Terraform and CloudFormation Before Misconfiguration Reaches Production

Not all IaC findings are equal. Start by ensuring your scanner reliably catches the misconfigurations most commonly exploited in real cloud breaches.

Publicly accessible storage: S3 buckets with block_public_acls = false or bucket-public-access-block resources missing. Azure Storage accounts with allow_blob_public_access = true. Google Cloud Storage buckets with allUsers or allAuthenticatedUsers IAM bindings. Public storage is responsible for more cloud data exposures than any other misconfiguration category.

Overly permissive network access: Security groups with ingress rules permitting 0.0.0.0/0 (any source) to ports 22 (SSH), 3389 (RDP), 5432 (PostgreSQL), 3306 (MySQL), or 6379 (Redis). These are the top five ports targeted by automated internet scanners. A database security group with 0.0.0.0/0 ingress is a critical finding that should block deployment.

IAM privilege escalation paths: IAM policies with "Action": "*" or "Resource": "*", inline policies attached directly to users rather than roles, and roles with the AdministratorAccess managed policy attached to non-administrative services. IaC scanners do not perform full privilege escalation graph analysis (that requires tools like PMapper or Cloudsplaining) but they catch the most obvious wildcard permission patterns.

Encryption disabled at rest and in transit: RDS instances without storage_encrypted = true, S3 buckets without server-side encryption configured, EBS volumes without encryption, and load balancers configured with HTTP rather than HTTPS listeners. Most compliance frameworks (PCI DSS, HIPAA, SOC 2) require encryption at rest and in transit as baseline controls.

Logging and monitoring gaps: CloudTrail disabled, VPC Flow Logs not enabled, S3 access logging disabled, and CloudWatch log groups without retention periods set. These are not directly exploitable but are required for incident response and create compliance gaps.

Checkov is the most widely adopted open-source IaC scanner, with the broadest framework coverage and the largest rule library. Developed by Bridgecrew (now part of Palo Alto Networks Prisma Cloud), it remains open source and receives active community contributions. Checkov outputs results in multiple formats including SARIF (for GitHub Code Scanning), JUnit XML (for CI pass/fail), and JSON for programmatic processing. Best choice for most organizations starting with IaC scanning.

tfsec is Terraform-specific and deeply optimized for Terraform HCL analysis. If your IaC is exclusively Terraform, tfsec provides faster scans and more Terraform-specific rules than general-purpose scanners. Now maintained as part of the aquasecurity ecosystem alongside Trivy.

KICS (Keeping Infrastructure as Code Secure) by Checkmarx has the broadest framework coverage and largest rule count, making it valuable in polyglot IaC environments. The tradeoff is higher false positive rates and longer scan times on large codebases.

The value of IaC scanning is zero if findings are reported but not acted upon. Integrate scanning into your deployment pipeline with hard failures on critical findings.

GitHub Actions integration pattern with Checkov:

- name: Run Checkov IaC scan
  uses: bridgecrewio/checkov-action@v12
  with:
    directory: ./terraform
    framework: terraform
    soft_fail: false
    check: CKV_AWS_18,CKV_AWS_20,CKV_AWS_57
    output_format: sarif
    output_file_path: results.sarif

- name: Upload Checkov results to GitHub
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: results.sarif

Set soft_fail: false to fail the pipeline on any finding. Start with a subset of critical checks using the check: parameter rather than enabling all rules immediately -- this prevents alert fatigue and gives developers a manageable remediation queue.

Pre-commit hooks for immediate feedback: Run IaC scanning as a pre-commit hook so developers see issues before pushing. The pre-commit framework supports Checkov, tfsec, and Terrascan. This gives the fastest feedback loop: finding a misconfiguration locally takes seconds to fix; finding it after a failed CI run takes 10-15 minutes.

Baseline and suppression management: Every team inherits legacy IaC with existing findings. Use a baseline file (Checkov supports --baseline flags) to track the existing finding count without failing builds on pre-existing issues, while blocking any new misconfigurations from being introduced. Suppression comments in Terraform code (# checkov:skip=CKV_AWS_18:Justification here) should require a documented justification and be reviewed in code review.

IaC scanners provide generic security rules. Policy as Code lets you enforce organization-specific requirements that generic rules cannot express: your company's required tags, approved AMI lists, mandatory backup retention periods, or region restrictions.

Open Policy Agent (OPA) with Conftest: OPA is a general-purpose policy engine. Conftest uses OPA's Rego policy language to validate structured data -- including Terraform plan JSON output. Write Rego policies that express your organizational requirements and run them against terraform plan -out=tfplan && terraform show -json tfplan output.

Example Rego policy requiring all S3 buckets to have versioning enabled:

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket"
  not resource.change.after.versioning[_].enabled
  msg := sprintf("S3 bucket '%v' must have versioning enabled", [resource.address])
}

HashiCorp Sentinel integrates directly into Terraform Cloud and Terraform Enterprise as the policy enforcement layer. Sentinel policies run after terraform plan and before terraform apply, with three enforcement levels: advisory (log but allow), soft-mandatory (warn but allow override with approval), and hard-mandatory (block with no override). Sentinel is the right choice for organizations using Terraform Cloud as their deployment platform; OPA/Conftest is better for teams with self-managed CI/CD.

Common organizational policies to encode:

• Require specific tags (Environment, Owner, CostCenter, DataClassification) on all resources
• Restrict deployment to approved AWS regions or Azure locations
• Require specific instance types or SKUs (preventing accidental large instance deployment)
• Enforce minimum backup retention periods for databases
• Require MFA delete on S3 buckets
• Restrict to approved AMI IDs or OS images

IaC scanning prevents misconfigurations at deployment time. But infrastructure drifts: developers make emergency changes in the console, automated systems modify resources, or manual changes bypass the IaC workflow. Drift detection identifies when your live cloud environment no longer matches the state defined in your IaC.

Terraform drift detection: terraform plan reports drift between the Terraform state file and the live cloud environment. Run terraform plan on a schedule (not just before deployments) in read-only mode and alert on any non-zero plan output. AWS Service Control Policies or Azure Policy can detect and alert on out-of-band console changes.

CSPM for continuous drift detection: Cloud Security Posture Management tools (Wiz, Orca, Prisma Cloud, AWS Security Hub) continuously scan your live cloud environment against security benchmarks. They are complementary to IaC scanning: IaC scanning prevents misconfigurations from being deployed; CSPM finds misconfigurations that exist in the running environment regardless of how they got there.

Drift remediation strategy: When drift is detected, the correct response depends on the cause. If a developer made a legitimate emergency change, import the change into the IaC state (terraform import) and submit it for code review. If the change is unauthorized, investigate it as a potential security incident -- unauthorized infrastructure changes are a lateral movement indicator. Never simply run terraform apply to overwrite a drifted state without investigating why the drift occurred.