Infrastructure as Code turned cloud infrastructure into software artifacts. That is mostly a good thing -- version control, peer review, automated deployment. But it also means your infrastructure inherits the same supply chain risks as your application code: misconfigurations get committed, insecure defaults propagate through templates, and third-party modules introduce vulnerabilities you did not write.
IaC security scanning catches these issues before they reach production. Done well, it shifts infrastructure security left without slowing down your deployment velocity. Done poorly, it floods developers with false positives and gets disabled within a month.
The Misconfiguration Problem
Cloud misconfigurations are consistently among the top causes of security breaches. The Capital One breach (2019) stemmed from an overly permissive IAM role. Countless S3 data exposures have resulted from public bucket policies. Default Kubernetes configurations routinely expose cluster APIs to the internet.
What makes IaC scanning uniquely valuable is timing. Finding a misconfigured S3 bucket in a Terraform plan is dramatically cheaper and faster than finding it after deployment through a cloud security posture management (CSPM) tool. The developer who wrote the code still has context, the fix is a one-line change to a pull request, and no data was ever at risk.
Terraform Security
Terraform is the most widely used IaC tool, and it has the most mature security scanning ecosystem.
Common Terraform Misconfigurations
S3 buckets without encryption:
resource "aws_s3_bucket" "data" {
bucket = "my-data-bucket"
# Missing: server_side_encryption_configuration
}
Security groups with overly broad ingress:
resource "aws_security_group_rule" "allow_all" {
type = "ingress"
from_port = 0
to_port = 65535
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"] # Open to the world
}
RDS instances without encryption at rest:
resource "aws_db_instance" "main" {
engine = "postgres"
instance_class = "db.t3.micro"
# Missing: storage_encrypted = true
}
Scanning Tools
Checkov: Open-source tool from Bridgecrew (Palo Alto) that supports Terraform, CloudFormation, Kubernetes, and more. It has over 1,000 built-in policies and supports custom policies written in Python or YAML. Checkov can scan Terraform plan files (not just HCL), which catches issues that only appear after variable resolution and module expansion.
tfsec (now part of Trivy): Focuses exclusively on Terraform and provides high-fidelity findings with low false positive rates. It understands Terraform semantics deeply, including module references and variable resolution.
Terrascan: Regal's open-source scanner that uses Open Policy Agent (OPA) for policy definition. Good for organizations that want to write custom policies in Rego.
Sentinel: HashiCorp's commercial policy-as-code framework. Integrates natively with Terraform Cloud and Enterprise. If you are already in the HashiCorp ecosystem, Sentinel provides the tightest integration.
Terraform Module Supply Chain
Terraform modules from the public registry are the IaC equivalent of npm packages. When you use a community module, you are trusting that module's author not to introduce misconfigurations or malicious resources.
Best practices for module security:
- Pin module versions explicitly (do not use
latest) - Review module source code before adoption
- Use private module registries for organizational standards
- Scan module source code with the same tools you use for your own Terraform
CloudFormation Security
AWS CloudFormation has a smaller ecosystem of dedicated scanning tools, but the major multi-tool scanners (Checkov, cfn-lint, cfn-nag) provide good coverage.
CloudFormation-Specific Risks
Overly permissive IAM policies: CloudFormation templates frequently include IAM policies with Action: "*" and Resource: "*". These are often created as "temporary" during development and never tightened.
Nested stack visibility: CloudFormation nested stacks can obscure the full resource configuration. Scanners need to resolve nested stacks to see the complete picture.
Custom resources: CloudFormation custom resources backed by Lambda functions can execute arbitrary code during stack deployment. This is an often-overlooked attack vector.
Scanning Approach
cfn-lint: Amazon's official linter for CloudFormation. It validates syntax and catches common errors but has limited security-specific rules.
cfn-nag: Stelligent's security scanner for CloudFormation. It provides warnings for insecure patterns like wildcard IAM permissions, unencrypted resources, and public network configurations.
Checkov: Supports CloudFormation alongside Terraform. If you use both tools in your organization, Checkov provides consistent scanning across both.
Kubernetes Manifest Security
Kubernetes security scanning is its own discipline, but the IaC scanning principles apply directly to Kubernetes manifests, Helm charts, and Kustomize configurations.
Common Kubernetes Misconfigurations
Running containers as root:
securityContext:
runAsUser: 0 # root
Missing resource limits (enabling resource exhaustion attacks):
containers:
- name: app
image: myapp:latest
# Missing: resources.limits
Privileged containers:
securityContext:
privileged: true # Full host access
Missing network policies (allowing unrestricted pod-to-pod communication): All pods can communicate with all other pods by default. Without NetworkPolicy objects, lateral movement within the cluster is trivial.
Scanning Tools
KubeSec: Scores Kubernetes resource definitions against security best practices. Simple to use but limited in customization.
Kube-bench: Checks Kubernetes cluster configuration against CIS Benchmarks. Focuses on the cluster itself rather than the workloads.
Polaris: Fairwinds' tool that validates Kubernetes resources against best practices. Supports both static scanning and runtime admission control.
OPA/Gatekeeper: Open Policy Agent with Gatekeeper provides admission control for Kubernetes. Policies written in Rego can enforce arbitrary constraints on resources at deployment time.
Integrating IaC Scanning into CI/CD
The integration point matters as much as the tool selection.
Pull Request Scanning
Run IaC scans on every pull request that modifies infrastructure code. Present findings as PR comments with inline annotations pointing to the specific line that needs to change. This is the highest-impact integration because it catches issues when the developer still has context and the fix cost is lowest.
Pre-commit Hooks
For faster feedback, run lightweight scans as pre-commit hooks. This catches the most common issues before code is even pushed. Keep pre-commit scans fast (under 30 seconds) to avoid developer friction.
Pipeline Gates
For enforcement, add IaC scanning as a pipeline gate that blocks deployment if critical findings are present. Start with a small set of high-confidence rules (no public S3 buckets, no wildcard IAM policies, no privileged containers) and expand over time.
Policy as Code
As your program matures, move from tool-specific rules to a policy-as-code framework (OPA, Sentinel, or Checkov custom policies). This lets you define organization-specific standards that are version-controlled, peer-reviewed, and consistently enforced across all IaC tools.
Dealing with False Positives
IaC scanners are notorious for false positives, particularly around context-dependent findings. A security group open to 0.0.0.0/0 is a critical finding for a database but expected for a public load balancer.
Handle this with:
- Inline suppressions: Most tools support inline comments that suppress specific findings with a justification. Require justifications and review them in code review.
- Baseline management: Establish a baseline of accepted findings and only alert on new findings. This prevents alert fatigue from legacy configurations.
- Contextual policies: Where possible, write policies that account for context (e.g., only flag public security groups on resources tagged as "internal").
How Safeguard.sh Helps
Safeguard.sh extends supply chain visibility to your infrastructure layer. When you generate SBOMs for your applications, Safeguard.sh also captures the infrastructure components -- Terraform providers, Kubernetes base images, and CloudFormation custom resource Lambda functions -- as part of your software inventory.
This means vulnerability correlation covers not just your application dependencies but also the infrastructure components they run on. When a vulnerability is discovered in a Terraform provider or a Kubernetes base image, Safeguard.sh identifies affected deployments and routes findings through the same triage and remediation workflow your team already uses for application vulnerabilities.