Scanning Terraform with Checkov before you apply

Catch public buckets and open security groups in the plan — in CI, with suppressions that expire and a clean baseline.

The Terraform changes that cause incidents are small diffs: a bucket policy with Principal: "*", a security group rule for 0.0.0.0/0 on port 22, an RDS instance created without storage_encrypted. Checkov reads the .tf files and matches them against a few thousand built-in checks, needs no cloud credentials to do so, and exits non-zero when it finds one. The tool is easy; the decisions are which findings should stop a merge, what to do about the four hundred findings in the stack that already exists, and how an exception is recorded so it does not become permanent.

What blocks, what warns

Gate design

Checkov expresses this with --hard-fail-on and --soft-fail-on, which accept check ids, and with a baseline. The two flags are not symmetrical. On the fixture, --hard-fail-on CKV_AWS_53 (a check the fixture passes) returned exit 0 with eleven failed checks still printed: once a hard-fail list exists, every check not on it is soft. --soft-fail-on CKV_AWS_20 alone still exited 1 on the other ten. So the hard-fail list is the whole gate, and a --soft-fail-on next to it is documentation for the reader rather than configuration. The flags also accept severity names, but the severity of a check comes from Prisma Cloud platform metadata and is only present when Checkov runs with an API key; on the open-source policies alone, gate by check id and by baseline rather than by a severity name that resolves to nothing.

checkov:
  stage: test
  image: bridgecrew/checkov:3.3.17          # pinned: the policy gate is itself a dependency
  script:
    - checkov -d terraform/ --framework terraform
        --baseline terraform/.checkov.baseline    # findings already known do not fail (the file lives where --create-baseline put it)
        --hard-fail-on CKV_AWS_20,CKV_AWS_53,CKV_AWS_54,CKV_AWS_55,CKV_AWS_56,CKV_AWS_24,CKV_AWS_25
        # everything not listed above is reported and does not fail the job
        --output cli --output gitlab_sast --output-file-path console,gl-sast-report.json
  artifacts:
    reports:
      sast: gl-sast-report.json               # findings appear on the merge request diff
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

The baseline: only new findings fail

A scanner introduced into an existing estate fails every merge on day one and is disabled on day two. checkov --create-baseline writes the current findings to a .checkov.baseline file inside the directory it scanned, not in the working directory, and that run is still a failing scan (exit 1), so it cannot sit in front of &&. From then on, --baseline compares each run against that file and fails only on findings that are not in it. The baseline is the debt register: it is committed, it is reviewed, and it should shrink. A pipeline that regenerates the baseline on every run has removed the gate while keeping the job green, which is worth a review comment when someone proposes it.

Exceptions with an owner and a date

An inline checkov:skip comment suppresses one check on one resource and carries a free-text reason. It has to be inside the resource block: placed on the line above resource, where most people put comments, Checkov 3.3.17 still reports the check as FAILED; on the first line inside the braces it is honoured and the reason is echoed in the output. The reason is the part that matters: a ticket id, who accepted the risk, and when it should be looked at again. Checkov does not expire skips by itself, so the expiry is enforced by the review of the comment and by a periodic grep for skips older than their date; a skip with no reason, or a --skip-check in the pipeline definition that hides a check from every resource, is the finding to raise in review.

# CDN origin bucket: public read is intended, the origin is fronted by CloudFront with OAC and WAF.
# Risk accepted by security (INFRA-442), review by 2026-12-31.
resource "aws_s3_bucket" "cdn_origin" {
  # checkov:skip=CKV_AWS_20:public-read origin behind CloudFront OAC and WAF; INFRA-442; review 2026-12-31
  bucket = "acme-cdn-origin"
}

When the gate is wrong: recovery in order of preference

Rules that are specific to your organisation (a mandatory cost-center tag, an approved list of AMIs, a KMS key that production databases must use) are custom policies in YAML or Python loaded with --external-checks-dir, and they run in the same job. When the rule depends on a computed value, a variable or a module output that is only known after terraform plan, a static scan of the HCL cannot evaluate it; that case belongs to a policy on the plan JSON, which OPA on Terraform plans covers.

The scan runs before terraform plan posts its output to the merge request, so a public bucket is a red job rather than a comment someone has to read. The apply side has its own guard: remote state with locking so the apply that follows a green scan is the only one running.

Related posts

Quick reference