Running it as a program

Policy, exceptions, metrics.

Advanced12 min · lesson 12 of 12

Beyond the CLI, running IaC scanning as a program means the organizational scaffolding: a central, versioned policy set (built-in checks plus your custom pack) distributed to every repo, a documented exception process (how a suppression gets approved, by whom, with an expiry), and metrics that show whether posture is improving. The tool is easy; making it stick across many teams without becoming shelf-ware is the real work.

Exceptions, ownership, and metrics

Three practices keep it healthy. Exceptions are tracked, justified, and time-boxed — an accepted risk gets a ticket and a review date, not a silent forever-skip. Ownership is clear — findings route to the team that owns the resource, not a central queue nobody drains. And metrics are visible — findings by severity over time, baseline burn-down, mean time to remediate — so leadership can see the program working and teams get credit for improving. Without these, scanning decays into ignored noise.

terminal

# distribute one org policy pack + custom checks to every repo’s CI
$ checkov -d . --external-checks-dir ./org-policies --config-file .checkov.yaml
# .checkov.yaml pins the frameworks, severities to gate, and the baseline centrally

Governance, not just tooling, makes scanning work

A scanner dropped into CI with no exception process, no ownership, and no metrics predictably becomes noise teams learn to ignore. Invest in the program: a reviewed central policy, time-boxed exceptions, findings routed to owners, and posture tracked over time. The tool catches misconfigurations; the governance is what turns caught misconfigurations into fixed ones.

Enforcing in CI/CDFinish · self-test