Infrastructure as Code Security Scanning

Infrastructure as Code (IaC) tools like Terraform, AWS CloudFormation, Ansible, and Helm allow infrastructure to be defined in version-controlled configuration files. This brings enormous benefits — repeatability, auditability, and automation — but also a critical security risk: misconfigurations in IaC files produce insecure infrastructure at scale. A single misconfigured Terraform module deployed across 50 environments creates 50 vulnerable systems simultaneously. IaC security scanning addresses this by checking configuration files before they are applied, shifting security left into the developer workflow.

Security scanning tools look for the most common IaC misconfigurations found in real-world cloud environments: S3 buckets with public access enabled or no encryption at rest; security groups with 0.0.0.0/0 inbound rules on sensitive ports (22, 3389, 1433); databases without encryption or with public accessibility; IAM policies with * resource or action wildcards; CloudTrail disabled in a region; KMS keys without key rotation; and load balancers with HTTP listeners instead of HTTPS. These findings closely mirror the checks performed by cloud security benchmarks like CIS AWS Foundations.

Checkov (by Bridgecrew/Prisma Cloud) is a popular open-source static analysis tool for IaC that supports Terraform, CloudFormation, Kubernetes manifests, Helm charts, and Dockerfiles. It ships with over 1,000 built-in policies mapped to CIS benchmarks, GDPR, SOC 2, and HIPAA. Running checkov -d . scans all IaC files in the current directory and produces a color-coded report of passed, failed, and skipped checks with resource paths and remediation guidance. Checkov can be integrated into CI/CD pipelines to block deployments when critical checks fail.

tfsec (now part of Trivy's IaC scanning capability) is a purpose-built Terraform security scanner that understands HCL syntax deeply, allowing it to trace values across modules and variable files. Unlike simpler scanners, tfsec can detect misconfigurations where the issue spans multiple files — for example, a security group rule that appears safe in isolation but is attached to a resource in another file. tfsec produces findings with severity levels (CRITICAL, HIGH, MEDIUM, LOW), CWE IDs, and direct links to remediation documentation, making findings actionable for developers.

One of the most critical IaC security issues is hardcoded secrets in configuration files — passwords, API keys, TLS private keys, and database connection strings committed to Git. Since IaC repositories are often shared across teams and stored in version control history, a secret committed even once is effectively compromised permanently (Git history is immutable). Tools like Checkov, detect-secrets, git-secrets, and TruffleHog scan for secret patterns. The fix is using input variables referenced from environment variables or secret stores, never hardcoded values.

Policy as Code (PaC) frameworks allow security teams to write custom rules in code and enforce them consistently. Open Policy Agent (OPA) with Conftest allows writing Rego policies that validate any structured data — Terraform plans, Kubernetes manifests, Helm values — in CI/CD pipelines. HashiCorp Sentinel is built into Terraform Enterprise and Cloud, allowing policies like 'all S3 buckets must have encryption enabled' to be enforced at plan time, blocking any apply that would violate the policy. These tools allow security requirements to be codified and version-controlled alongside the infrastructure they govern.

Configuration drift occurs when the actual state of deployed infrastructure deviates from the IaC definition — often because someone made a manual change through the cloud console. A security group rule added manually to 'temporarily' unblock a developer becomes a permanent gap. Drift detection tools continuously compare the desired state (IaC files) against the actual deployed state and alert on deviations. AWS Config, Terraform Cloud's drift detection, and CSPM tools (Prisma Cloud, Wiz) all provide this capability. Security misconfigurations introduced through console changes are caught before attackers discover them.

Immutable infrastructure means that servers and configurations are never modified in place — instead, changes create new resources (new AMIs, new container images) and replace old ones. Combined with GitOps (where all infrastructure changes must flow through a Git pull request, triggering IaC scanning and approval workflows), this eliminates configuration drift by construction: if something cannot be changed manually, it cannot drift. Tools like ArgoCD for Kubernetes and Atlantis for Terraform implement GitOps workflows where any deviation triggers an automatic reconciliation or alert.

IaC security scanning is sometimes confused with SAST (Static Application Security Testing), but they target different artifacts. SAST analyzes application source code (Python, Java, JavaScript) for vulnerabilities like SQL injection or buffer overflows. IaC scanning analyzes infrastructure configuration files for cloud security misconfigurations — no application code is involved. A complete DevSecOps pipeline includes both: SAST on application code and IaC scanning on infrastructure files. Both run in CI/CD before any deployment. Some unified platforms (Snyk IaC, Prisma Cloud) combine application and infrastructure scanning in a single tool.

Effective IaC security scanning must be automated and enforced — not optional. A typical CI/CD integration: on every pull request, run Checkov and tfsec; fail the pipeline if CRITICAL findings exist; post findings as pull request comments for developer visibility; maintain a list of suppressed findings with documented justifications; and run a nightly scan against deployed resources for drift. Pre-commit hooks using tools like pre-commit with Checkov can catch issues even before code reaches the pipeline. False positive management is important — developers who see too many irrelevant findings start ignoring them.

Terraform's state file (terraform.tfstate) contains the complete inventory of all managed resources, often including sensitive output values like database passwords, TLS private keys, and IAM access key IDs in plaintext. State files must never be committed to Git. Instead, use a remote backend (AWS S3 with DynamoDB locking, Terraform Cloud, or GitLab-managed state) with server-side encryption enabled. Access to the state backend must be strictly controlled via IAM — anyone who can read the state file can enumerate all infrastructure details and potentially extract embedded secrets.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: IaC misconfigurations like public S3 buckets, open security groups, and hardcoded secrets are automatically detected by tools like Checkov and tfsec before deployment, Policy as Code frameworks (OPA/Conftest, HashiCorp Sentinel) allow custom organizational security requirements to be enforced as automated pipeline gates, and Terraform state files must be stored in encrypted remote backends with strict access controls as they may contain sensitive resource details. Next up we explore the APT lifecycle and how advanced threats persist inside networks.