What Checkov Catches — and What It Misses

Checkov applies a library of checks — currently over 1,000 for Terraform (as of April 2026) — each of which evaluates a specific attribute on a specific resource type against a known-bad condition.CKV_AWS_79checks that http_tokens = "required" is set on aws_instance.CKV_AWS_19checks that server-side encryption is configured onaws_s3_bucket_server_side_encryption_configuration. These are deterministic: pass or fail, no judgment required.

This model is fast, reproducible, and free of false negatives for the conditions it checks. It is also necessarily bounded. A check can only evaluate what is present in the resource attributes it reads. It cannot reason about:

• ·Relationships between resources — whether an IAM role can access a specific S3 bucket, or whether a Lambda can assume a cross-account role.
• ·The workload context — whether this database is a production critical-path store or a dev scratch environment that does not need multi-AZ.
• ·The blast radius of a finding — what else becomes accessible if this specific configuration is exploited.
• ·Patterns that emerge from what is absent — a Lambda function missing a Dead Letter Queue, an RDS instance missing cross-region automated backups, a VPC with no Flow Logs.

None of these limitations are bugs in Checkov. They are architectural properties of static rule-based analysis. The tool is doing exactly what it is designed to do.

A Checkov check has the same severity regardless of whether it runs against your production customer database or a developer’s temporary sandbox. A Well-Architected review, by contrast, asks about workload context first: what is this service’s SLA? Who are the users? What is the recovery time objective?

A dev RDS instance without multi-AZ is a cost-appropriate choice. The same configuration on a production database handling payment data is a Reliability pillar finding (REL 10: “How do you use fault isolation to protect your workload?”). The Terraform is identical — only the context changes the severity.

Not all misconfigurations are equal. An overly permissive IAM role on a Lambda function that only processes non-sensitive queue messages carries very different blast radius than the same policy on an EC2 instance with access to a KMS key that encrypts customer PII.

Checkov reports both as identical violations ofCKV_AWS_40orCKV_AWS_289. An architectural review maps the lateral movement path: if this role is compromised, which other resources are reachable, and in what sequence?

A healthcare SaaS has different risk priorities than a batch data pipeline or an e-commerce checkout service. The AWS Well-Architected Framework has six pillars, and their relative weight depends on the workload. A linter applies the same ruleset to every Terraform file regardless.

Every standard Checkov S3 check passes on this bucket: the ACL is private, encryption is enabled, and public access is blocked. What Checkov does not check is whether the bucket policy grants access to a principal that is broader than the workload requires.

This RDS instance has encryption at rest, deletion protection, and a 7-day backup retention period — all checked by Checkov. The one configuration that determines whether this database survives an AZ failure is multi_az, and Checkov has no rule for it.

Checkov has no rule that checks for a dead_letter_config block on Lambda functions. For synchronous Lambda invocations — where the caller receives the response and handles failures — this may be acceptable. For asynchronous invocations — S3 event triggers, SNS subscriptions, EventBridge rules — it is an Operational Excellence finding.

The answer is not to replace Checkov — it is to understand what each layer covers.

Checkov belongs in CI as a fast, mandatory gate on known-bad configurations. It catches attribute-level violations early, before code review, and with zero false-negative risk for the conditions it checks. Nothing else does this as well.

Architectural review belongs at the workload level: before production deployments, before major architectural changes, and periodically as infrastructure evolves. It operates on the Terraform as a system — reading relationships between resources, mapping blast radius, and evaluating findings against the workload context.

The ArchGuard methodology explicitly runs deterministic checks first, then layers architectural reasoning on top. Checkov findings are an input — not something ArchGuard competes with.

For a deeper treatment of the five most common Terraform patterns that pass Checkov but fail a Well-Architected Security review — with HCL before/after examples — that post walks through each one with the specific WAF control it violates.