IaC Security Findings: AI as Explainer, Scanner as Truth

Tier: Foundation · Workflow area: Infrastructure as Code

Commercial tools now open fix PRs automatically; this playbook builds the same loop with OSS parts, keeping the trust boundary explicit — AI never decides whether something is a finding.

When to use

• •
  A repo's scanner backlog has grown past the point anyone reads it.
• •
  Adopting a scanner on a legacy IaC estate and facing 400 findings on day one.
• •
  Recurring PR-time findings that juniors fix slowly because the finding text is opaque.

Skip AI for a repo with three findings — just fix them.

Prerequisites

• •
  A scanner wired to produce machine-readable output: checkov -d . -o json or trivy config --format json .
• •
  An AI assistant or LLM API access.
• •
  Git context: who owns which module (CODEOWNERS), which stacks are prod vs sandbox.

The workflow

1. 1.

   Run the scanner; export JSON. The scanner output is the source of truth for the entire workflow — AI adds no findings and removes none:

   Copy

   checkov -d infra/ -o json > findings.json
   jq '.results.failed_checks | length' findings.json
   

2. 2.

   Ask for contextual triage, not re-scanning.

   Copy

   Attached: Checkov findings JSON for our Terraform repo, plus a map of
   which stacks are production.
   
   For each distinct check ID:
   1. Explain the actual risk in one paragraph — in terms of what an attacker
      or an outage does with it, not compliance language.
   2. Classify urgency: NOW (internet-exposed or prod data risk),
      SPRINT (prod, not exposed), BACKLOG (sandbox/dev only).
   3. Note which findings are likely false positives given the context
      (e.g., intentionally public static-site bucket) — flag, do not dismiss.
   Do not add findings the scanner did not report. Do not mark anything
   resolved.
   

3. 3.

   Verify the triage sample-wise. Spot-check: every NOW item — confirm the resource really is prod/exposed (the model only knows what you attached); every "likely false positive" — confirm against the actual code before anyone skips it.

4. 4.

   Draft fixes in small, owner-aligned batches.

   Copy

   Draft the Terraform changes to fix these 6 CKV_AWS_16 findings (RDS
   encryption) in modules/database. Constraints: use the existing kms_key_id
   variable pattern from modules/storage; do not change instance sizes or
   any attribute unrelated to the finding; note that enabling encryption on
   an existing unencrypted RDS instance requires snapshot-restore — produce
   the runbook steps for that, not just the HCL.
   

   That last constraint is the difference between a useful fix PR and a landmine: some security fixes (RDS encryption, some S3 settings) force replacement of stateful resources. The AI must be made to surface migration impact, and you must read the plan.

5. 5.

   Route each batch through the standard chain (validate → plan → policy → cost, pb-08). The plan gate is where "this fix replaces the production database" becomes visible. Policy gate confirms the finding count actually dropped.

6. 6.

   Institutionalize skips. Where a finding is accepted risk, encode it as an inline skip with justification — AI drafts these too, humans approve:

   Copy

   #checkov:skip=CKV_AWS_18:Access logging handled centrally via org CloudTrail; ticket SEC-482
   

Tool variants

• Checkov/tfsec/Trivy + chat assistant (shown): zero new spend, works today.
• Scanner + LLM API in CI: post the triaged, explained summary as a PR comment instead of raw finding IDs — pairs naturally with the advisory reviewer from pb-04.
• Commercial auto-fix agents (e.g., Datadog Bits Dev Agent, Snyk fix PRs): same pattern productized; still route their PRs through your plan gate — vendor automation does not get an apply shortcut.

Verification

• Validate: fix branches pass terraform validate + TFLint.
• Plan: reviewed for every fix batch; any resource replacement on stateful infra called out explicitly in the PR and scheduled deliberately.
• Policy: re-run the scanner post-merge; finding count for the targeted check IDs is provably lower; no new findings introduced by the fixes.
• Cost: Infracost diff on fix batches — security fixes that add KMS keys, logging buckets, and flow logs have real costs; surface them, don't discover them.

Pitfalls

• AI-invented finding IDs. When asked about scanner output, models sometimes cite check IDs that do not exist or misdescribe what a real ID checks. Explanations must trace back to the JSON you provided.
• Stateful-resource replacement hiding in a "simple" fix. Encryption and some networking fixes force destroy/recreate. Only the plan shows this. Read it.
• Batch fixes that mix concerns. One PR fixing 30 findings across 12 modules is unreviewable and unrevertable. Batch by check ID and owner.
• Skip rot. Skips without tickets/justifications accumulate into an unauditable exception pile. Make justification-plus-ticket the enforced format from day one.

Restricted-environment variant

Findings JSON contains resource names, ARNs, account IDs. For client estates: run scanners inside the client boundary (all OSS), and either use the client's in-tenancy AI endpoint for triage, or strip identifiers (jq transform replacing resource addresses with stable hashes) before external triage and re-map locally. The explanation step needs check IDs and resource types, not real names — redaction costs little here.

Success criteria

• •
  Backlog triaged into NOW/SPRINT/BACKLOG with human-verified NOW items, in under a day.
• •
  First fix batches merged through the full chain with zero surprise replacements.
• •
  Scanner finding count trending down week over week, visible in CI.
• •
  Every skip in the codebase carries a justification and a ticket reference.