Infrastructure-as-Code Security Scanning

Infrastructure-as-Code (IaC) is the practice of managing and provisioning infrastructure through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. IaC security scanning is the process of analyzing these definition files—such as Terraform configurations, AWS CloudFormation templates, Kubernetes manifests, and Ansible playbooks—for security misconfigurations, compliance violations, and best practice deviations before the infrastructure is deployed.

The core principle is 'shift left'—moving security checks earlier in the software development lifecycle (SDLC). Instead of scanning a live environment and then tearing down or patching misconfigured resources, IaC scanners catch issues at design time, when changes are cheap and fast. This is analogous to static application security testing (SAST) but for infrastructure definitions.

IaC scanners operate in three main phases: parsing, rule evaluation, and report generation.

Parsing: The scanner reads the IaC file and converts it into an internal representation, typically an abstract syntax tree (AST) or a structured data model. For example, a Terraform HCL file is parsed into a tree of blocks and attributes; a CloudFormation JSON template is parsed into a JSON object. The scanner must understand the specific syntax and semantics of each IaC language.

Rule Evaluation: The scanner applies a set of security rules against the parsed representation. Rules are typically written in a declarative language such as Rego (used by Open Policy Agent), Python, or custom DSLs. Each rule checks for a specific condition. For instance, a rule might check if an AWS S3 bucket has acl = "public-read" or if a security group allows inbound traffic on port 22 from 0.0.0.0/0. Rules are organized by severity (Critical, High, Medium, Low) and by standard frameworks (CIS Benchmarks, NIST 800-53, PCI DSS).

Report Generation: The scanner outputs a list of findings, each containing:

IaC Languages Supported: - Terraform (HCL) - AWS CloudFormation (JSON/YAML) - Kubernetes manifests (YAML) - Ansible (YAML) - Dockerfile - ARM templates (Azure) - Google Deployment Manager (YAML)

Common Scanning Tools: - Checkov (open-source, Python-based) - Terrascan (open-source, Go-based) - tfsec (Terraform-specific, now part of Trivy) - Snyk IaC (commercial, supports multiple languages) - Bridgecrew (commercial, now part of Prisma Cloud) - KICS (Keeping Infrastructure as Code Secure, open-source)

Default Severity Levels: - Critical: Direct exposure of sensitive data or full compromise (e.g., S3 bucket public access) - High: Misconfigurations that could lead to privilege escalation or lateral movement (e.g., overly permissive IAM policies) - Medium: Violations of best practices that increase attack surface (e.g., missing encryption at rest) - Low: Informational findings, such as missing tags or logging recommendations

Common Rules Checked: - Storage bucket public access (S3, Blob Storage) - Security groups allowing 0.0.0.0/0 on sensitive ports (SSH, RDP, MySQL) - Encryption disabled on storage or databases - Hardcoded secrets (passwords, API keys, tokens) - IAM policies with wildcard actions or principals - Kubernetes pods running as root or with privileged containers - Missing network segmentation (e.g., all subnets in a VPC)

Checkov Example:

# Install Checkov
pip install checkov

# Scan a Terraform directory
checkov -d /path/to/terraform

# Scan a specific file
checkov -f /path/to/main.tf

# Scan with a custom skip rule
checkov -d . --skip-check CKV_AWS_23

# Output results in JSON format
checkov -d . -o json

Terrascan Example:

# Install Terrascan (via brew or binary)
brew install terrascan

# Scan a Terraform directory
terrascan scan -d /path/to/terraform

# Scan a specific file
terrascan scan -f /path/to/main.tf

# Use a specific policy path
terrascan scan -d . --policy-path /path/to/custom/policies

tfsec (Trivy) Example:

# Install tfsec
brew install tfsec

# Scan a directory
tfsec /path/to/terraform

# Scan with custom severity threshold
tfsec /path/to/terraform --severity-threshold CRITICAL

# Output in SARIF format for integration with GitHub
tfsec /path/to/terraform --format sarif > results.sarif

IaC scanning is typically integrated into CI/CD pipelines as a gate. For example, in a GitHub Actions workflow:

name: IaC Security Scan
on: [pull_request]
jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run Checkov
        run: |
          pip install checkov
          checkov -d . --soft-fail

If --soft-fail is omitted, the pipeline will fail on any finding with severity above a configurable threshold, blocking the pull request. This ensures that no misconfigured infrastructure reaches production.

Consider the following Terraform snippet:

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-unique-bucket-name"
  acl    = "public-read"
}

resource "aws_security_group" "allow_ssh" {
  name        = "allow_ssh"
  description = "Allow SSH inbound traffic"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

An IaC scanner like Checkov would produce findings: - CKV_AWS_20: S3 Bucket has an ACL defined which allows public access. (Severity: CRITICAL) - CKV_AWS_23: Security group allows ingress from 0.0.0.0:0 to port 22. (Severity: HIGH)

Remediation would involve removing the acl line (or setting it to private) and restricting the cidr_blocks to a specific IP range.

IaC security scanning is a foundational practice for modern DevSecOps. By catching misconfigurations before deployment, organizations reduce their attack surface, achieve compliance more easily, and avoid costly post-deployment fixes. For the CS0-003 exam, focus on understanding the types of misconfigurations scanners detect, how to interpret their output, and how they fit into the broader vulnerability management lifecycle.

In a large enterprise, IaC security scanning is typically integrated into a centralized DevSecOps platform. For example, a financial services company uses Terraform to manage hundreds of AWS accounts. They deploy Checkov in their GitLab CI pipeline, scanning every pull request against a custom policy library that enforces PCI DSS requirements. The pipeline is configured to fail on any CRITICAL or HIGH finding, blocking the merge. Developers receive immediate feedback in the merge request comments via a Checkov integration. Common misconfigurations caught include S3 buckets with public read access, security groups open to 0.0.0.0/0, and unencrypted RDS instances. The team also runs a weekly scan of all IaC repositories using a scheduled pipeline to catch any drift or newly introduced issues. Performance is a consideration: scanning a large Terraform project with hundreds of modules can take several minutes. To mitigate this, the team uses incremental scanning—only scanning changed files in pull requests—and caches module downloads. When misconfigurations slip through, such as when a developer bypasses the pipeline using a hotfix branch, the team relies on a CSPM tool (e.g., AWS Security Hub) to detect the misconfiguration in production and trigger a remediation workflow. Another scenario involves a SaaS provider using Kubernetes and Helm charts. They integrate Terrascan into their Argo CD pipeline to scan Helm values and templates before deployment. A common issue is container images running as root or with privileged capabilities. The scanner catches these and suggests adding securityContext settings. The team also uses custom policies to enforce internal standards, such as requiring all ingress controllers to have TLS termination. When the scanner produces false positives, such as flagging a public ALB as a security risk when it is intentionally public for a customer-facing web app, the team adds skip annotations to the IaC code with a justification. This ensures that the scan remains useful without blocking legitimate deployments. Over time, the team builds a library of exceptions that are reviewed quarterly.