Why Checkov and IaC Scanning Aren't Enough for Runtime Security
IaC scanning (Checkov, tfsec) catches pre-deployment misconfigurations. But console changes, drift, and runtime state need CSPM. Here's why you need both.
The IaC Scanning Promise
Checkov, tfsec, and similar tools scan your Infrastructure-as-Code (Terraform, CloudFormation, Kubernetes manifests) before deployment. They catch misconfigurations at the source — before they reach production.
The idea is compelling: shift security left. If every infrastructure change goes through code review and automated scanning, misconfigurations never make it to production.
In practice, this only works if every infrastructure change goes through code.
The Gap Between Code and Reality
Console Changes
Engineers make changes through the cloud console. Maybe it’s an urgent fix during an incident. Maybe it’s a developer testing something who forgets to codify it. Maybe it’s a contractor who doesn’t have access to the Terraform repo.
These changes bypass IaC scanning entirely. Checkov never sees them because they never exist in code.
Configuration Drift
Even in mature IaC shops, drift happens. Someone runs terraform apply from a feature branch without merging. A cloud provider auto-updates a managed service setting. A support ticket resolution changes a configuration outside your IaC state.
The Terraform state file says one thing. The actual cloud API says another. Checkov checks the code. The code matches the state. But the state doesn’t match reality.
Service-Level Defaults
Cloud providers change defaults over time. An S3 bucket created in 2022 has different default encryption settings than one created in 2024. Your Terraform code might not specify encryption explicitly (relying on the old default), but Checkov won’t flag it because the code is syntactically valid.
The actual deployed bucket, however, might not have the encryption settings you expect.
Resources Not in IaC
Most organizations have resources that predate their IaC adoption, or resources in accounts that aren’t managed by Terraform. Legacy VPCs, hand-created IAM users, old S3 buckets from proof-of-concepts. These exist, they may have security issues, and IaC scanning can’t see them.
What IaC Scanning Does Well
To be clear, Checkov and similar tools are valuable:
- Catch issues early — before deployment, in CI/CD, during code review
- Developer-friendly — feedback in the PR, not in a security dashboard weeks later
- Policy as code — custom rules in Python/Rego that enforce organizational standards
- Wide coverage — Terraform, CloudFormation, Kubernetes, Dockerfiles, ARM templates
Checkov specifically offers 1,000+ built-in rules covering CIS benchmarks and cloud security best practices.
What CSPM Adds
CSPM (Cloud Security Posture Management) scans the actual deployed state of your cloud infrastructure via cloud APIs. It checks what’s actually running — not what your code says should be running.
| Capability | IaC Scanning (Checkov) | CSPM (Kloudle) |
|---|---|---|
| Checks code before deploy | Yes | No |
| Checks deployed state | No | Yes |
| Catches console changes | No | Yes |
| Detects drift | No | Yes |
| Finds unmanaged resources | No | Yes |
| Continuous monitoring | CI/CD only | Scheduled/continuous |
| Covers non-IaC environments | No | Yes |
| Real-time compliance status | No | Yes |
The Complementary Model
The correct approach is both, not either-or:
Code ──→ Checkov (CI/CD) ──→ Deploy ──→ CSPM (continuous)
│ │
│ "Does the code have issues?" │ "Does reality have issues?"
│ │
▼ ▼
Fix in PR Alert + remediateIaC scanning is your first line of defense. CSPM is your continuous verification that reality matches intent.
Common Objections
”We have 100% IaC coverage”
No you don’t. Check for resources in your cloud accounts that aren’t in any Terraform state file. Every organization has orphaned resources, manually created IAM entities, or cloud-provider-managed resources that IaC doesn’t cover.
”We prevent console access”
Good. But do you prevent:
- AWS Support from making changes during a ticket?
- Cloud provider auto-updates to managed services?
- Terraform applies from local machines during incidents?
- Resources created by AWS services themselves (e.g., Lambda execution roles)?
”Checkov catches everything Terraform can misconfigure”
Checkov checks what the code says. It doesn’t check what the code doesn’t say. A missing encryption block isn’t a misconfiguration in code — it’s a reliance on defaults. Defaults change. CSPM checks the actual state.
How Kloudle Complements Checkov
Teams using Checkov in CI/CD add Kloudle for continuous runtime verification:
- Checkov catches issues before they’re deployed (shift left)
- Kloudle catches issues that bypass IaC (console changes, drift, unmanaged resources)
- Together they provide full lifecycle coverage — from code to runtime
Kloudle runs 1,890 checks across AWS, GCP, Azure, DigitalOcean, and Kubernetes. Many overlap with Checkov’s rules (intentionally) — the difference is Kloudle checks deployed state while Checkov checks code.