IaC Security Scanning Checklist for Terraform, CloudFormation, and Kubernetes Manifests

Overview

If you manage cloud infrastructure through code, security scanning should start before resources ever reach a live environment. Terraform security scanning, CloudFormation security scanning, and Kubernetes manifest scanning all aim at the same goal: catch risky configurations early enough that developers can fix them in code, review them in pull requests, and keep the same mistake from repeating.

A useful IaC security scanning checklist does more than ask whether a scanner ran. It helps teams verify four things:

• Coverage: Are all infrastructure definitions scanned, including modules, overlays, charts, and generated files that actually shape production?
• Policy relevance: Do the rules reflect your real cloud services, networking model, identity model, and compliance needs?
• Developer workflow fit: Are findings visible in pull requests and CI/CD, with enough context to fix them quickly?
• Prioritization: Are teams focusing first on exploitable, exposed, or business-critical misconfigurations rather than treating all findings as equal?

This is where automated security scanning becomes more useful. A scanner can flag a public storage bucket or a privileged container quickly, but your workflow still needs ownership, severity rules, exception handling, and remediation guidance. If you already use scan gates in code review, pair this checklist with How to Add Security Scan Gates to Your Pull Request Workflow. If you need help ranking findings by actual risk, review Risk-Based Vulnerability Prioritization: How to Score Findings Beyond CVSS.

Use the checklist below in three layers: baseline checks that apply everywhere, scenario-specific checks by IaC type, and a final double-check pass before merge or deployment.

Checklist by scenario

Start with the controls that should apply to nearly every infrastructure repository, then move into Terraform, CloudFormation, and Kubernetes specifics. The goal is not maximum rule count. The goal is a checklist your team can actually maintain.

Baseline IaC security scanning checklist

• Scan every repository that defines deployable infrastructure, including mono-repos, environment-specific directories, shared modules, Helm charts, and templates.
• Run scans locally where practical and enforce them again in CI/CD so developers get feedback early and the pipeline remains the source of record.
• Check both changed files and full project context. A small diff can still create a risky resource through inheritance, variables, or module reuse.
• Fail builds on clearly high-risk issues such as public exposure of sensitive services, wildcard administrative privileges, disabled encryption, or privileged workload settings.
• Record lower-confidence or lower-severity findings without blocking delivery if your team has a documented triage process.
• Tag findings by environment, service owner, repository, and asset criticality so remediation work reaches the right team.
• Store scan results in a system where you can track status, suppressions, and recurring issues over time.
• Require justification and expiry dates for exceptions so temporary risk acceptance does not become permanent drift.
• Map core policies to your control framework if you need compliance-ready vulnerability management, especially for audit evidence.
• Review scanner coverage for cloud-specific services you actually use. Generic policies often miss organization-specific risk.

Terraform security scanning checklist

• Verify that remote state is protected with appropriate access controls and encryption, especially if state may include sensitive values or resource metadata.
• Check whether secrets, tokens, or private keys are being passed through variables, outputs, or local values in ways that could leak into logs or state files.
• Flag security groups, firewall rules, and network ACLs that allow broad inbound access such as unrestricted internet exposure to administrative ports or internal services.
• Review IAM policies, roles, and trust relationships for wildcard actions, wildcard resources, or cross-account assumptions that are broader than necessary.
• Check storage resources for public access, weak bucket policies, missing encryption, or absent versioning where recovery matters.
• Inspect databases, queues, and managed services for encryption at rest, secure transport requirements, and public endpoint exposure.
• Confirm logging and monitoring settings for critical resources, including audit trails, flow logs, or service-specific logs where available.
• Review module sources and versions. Unpinned or loosely pinned modules can introduce drift and make security review harder.
• Scan generated plans if your workflow supports it, not just static configuration. Plans can reveal risky defaults after variables and modules are resolved.
• Check destroy protections, retention settings, and backup-related options for critical infrastructure, especially when availability matters as much as confidentiality.

Terraform often hides complexity inside reusable modules. That is efficient for platform teams, but it also means one weak module can spread insecure defaults across many services. As part of infrastructure as code security, review the module once and enforce safe defaults there instead of relying only on downstream projects to override them correctly.

CloudFormation security scanning checklist

• Review IAM resources for excessive permissions, especially inline policies and trust policies attached to roles used by workloads or deployment automation.
• Check security groups and resource policies for unnecessary public access or unrestricted source ranges.
• Inspect parameters, mappings, and stack outputs for sensitive data exposure, including values that should come from a secret manager rather than plain template inputs.
• Confirm encryption settings for storage, databases, and messaging resources.
• Check whether logging, audit, and retention settings are enabled for services that support them.
• Review stack update and deletion protections for critical infrastructure.
• Validate template conditions and nested stacks so environment-specific logic does not accidentally disable a required control in production.
• Examine custom resources carefully. They can bypass the assumptions of standard static checks because the real behavior lives in code or functions outside the template.
• Check for overly permissive resource-based policies on storage, serverless functions, APIs, and event services.
• Ensure naming, tagging, and ownership metadata are included so findings can be routed and audited later.

CloudFormation security scanning can be deceptively clean if your scanner only evaluates obvious resource properties. Pay extra attention to nested stacks, macros, transforms, and custom resources, because these often carry the real logic.

Kubernetes manifest scanning checklist

• Block privileged containers unless there is a documented, reviewed need.
• Check for containers running as root, missing user settings, or writable root file systems where read-only is feasible.
• Require explicit resource requests and limits to reduce noisy-neighbor problems and support basic workload hardening.
• Review capabilities, host networking, host PID, host IPC, and hostPath mounts for unnecessary access to the underlying node.
• Check whether service accounts are overused, auto-mounted by default, or granted broad RBAC permissions beyond the workload's purpose.
• Inspect ingress, services, and network policies for unintended exposure between namespaces or to the public internet.
• Require image references that are pinned appropriately and sourced from approved registries where possible.
• Check admission-related labels, annotations, and policy expectations so workloads do not bypass namespace or cluster guardrails.
• Review secrets usage. Plain environment variables, embedded secret values, or weak secret management patterns should be flagged.
• Inspect pod security settings such as seccomp, privilege escalation controls, and read-only filesystem settings.
• Check liveness, readiness, and startup probes for operational resilience; weak operational settings can turn a security event into an outage faster.
• Scan Helm chart values and overlays, not only the rendered base manifests you happen to store in one directory.

Kubernetes manifest scanning works best when paired with container security scanning and API-level review. A hardened manifest still depends on the image it runs and the services it exposes. For adjacent guidance, see Container Security Scanning Best Practices for Images, Dependencies, and Runtime and API Security Scanning Checklist: What to Test in REST, GraphQL, and gRPC APIs.

CI/CD and review workflow checklist

• Run IaC scans on pull requests so reviewers see findings before merge.
• Use severity thresholds that distinguish between blocking issues and advisory issues.
• Attach remediation guidance to findings, ideally with file paths, line references, and safer configuration examples.
• Deduplicate repeated findings across branches and environments to reduce alert fatigue.
• Track mean time to remediate for recurring misconfiguration categories so you can improve templates and modules upstream.
• Route high-risk findings to both the infrastructure owner and the security owner if ownership is shared.
• Keep a suppression process with review dates, because ignored IaC findings often survive for many releases.

What to double-check

After the scanner runs, do one short manual pass. This is where many teams catch the gaps that automation alone misses.

• Resolved configuration: Did variables, modules, transforms, chart values, or overlays change the effective configuration in a way the raw file does not make obvious?
• Internet reachability: Is a resource not only public in policy, but actually reachable through networking, load balancers, or DNS?
• Privilege chains: Could a modest permission in one resource combine with another trust relationship to create broader access than any single finding suggests?
• Secrets handling: Even if a template does not hardcode a secret, does the deployment path expose it through state, logs, outputs, or environment variables?
• Environment differences: Are production settings genuinely stricter than development, or have convenience defaults leaked into higher environments?
• Policy intent: Is a finding truly a false positive, or is the rule exposing a real exception that your team has normalized?
• Compliance traceability: If you need evidence for audits, can you show scan execution, findings, approvals, and remediation history?

This review is also the right time to prioritize. A private but noncompliant setting may matter less than a publicly reachable service with broad permissions. For teams trying to reduce alert fatigue, risk-based vulnerability management is more useful than raw finding counts. Scan results become more actionable when they reflect exposure, privilege, data sensitivity, and business criticality rather than severity labels alone.

If your cloud program extends beyond infrastructure definitions into posture management, compare your pipeline checks with runtime and account-level visibility in Cloud Security Scanning Explained: CSPM vs CWPP vs CIEM.

Common mistakes

Most infrastructure as code security programs do not fail because teams forgot to buy a scanner. They fail because the process around the scanner is weak.

• Scanning only the main branch: This catches issues late, after design momentum and release pressure make fixes harder.
• Treating all findings as equal: A noisy rule set creates backlog without reducing meaningful risk.
• Ignoring modules and generated output: Shared abstractions can be the real source of insecure defaults.
• Suppressing findings without expiry: Temporary exceptions tend to become permanent.
• Separating security from developer workflow: If remediation requires leaving the PR context and hunting through another tool, fix rates usually drop.
• Missing ownership metadata: Findings age badly when nobody knows who should act.
• Relying on static IaC checks alone: Infrastructure code should be paired with cloud security scanning, container checks, and application or API scanning where relevant.
• Using compliance as the only lens: Passing an internal policy baseline does not guarantee low exploitable risk.

Another common issue is measuring success by the number of policies enabled. A smaller policy set that blocks the most dangerous mistakes is usually more sustainable than a very broad set that developers learn to ignore.

When to revisit

This checklist should be updated on a schedule and whenever your delivery model changes. Revisit it before seasonal planning cycles, before major platform changes, and after incidents or near misses. The best checklist is the one that evolves with your architecture.

Review and refresh your IaC security scanning checklist when any of the following happens:

• You adopt a new cloud service, Kubernetes pattern, or deployment model.
• You centralize infrastructure into new reusable modules, templates, or Helm charts.
• You change CI/CD tooling, branch protection, or pull request review rules.
• You add a new compliance requirement or need stronger audit evidence.
• You notice recurring false positives or recurring misconfigurations that your current policies do not prevent.
• You change team ownership boundaries between application, platform, and security teams.
• You experience a production exposure, access issue, or drift problem tied to configuration.

For a practical next step, pick one repository from each IaC type you use and answer five questions this week:

1. Are scans running on every pull request?
2. Do we block only the findings that truly justify a stop-ship decision?
3. Can a developer understand exactly how to fix a failed check?
4. Do we track exceptions with owners and expiration dates?
5. Have we updated policies to reflect the cloud and Kubernetes features we use today, not six months ago?

If the answer to any of those is no, your next improvement is already clear. From there, connect this checklist to your remediation timelines with Vulnerability SLA Matrix: How Fast Should Critical, High, and Medium Findings Be Fixed? and to audit evidence with SOC 2 Vulnerability Management Checklist for Security Scanning Programs. That turns IaC scanning from a point-in-time activity into a repeatable, compliance-ready workflow.