What it is
An API that takes a Terraform plan and returns the policy violations it contains — public storage buckets, unencrypted volumes, over-broad IAM, security groups open to the internet — each with a severity and a description of how to fix it.
It runs in CI, so the feedback lands on the pull request that introduced the problem.
The problem
Cloud misconfiguration is rarely exotic. It is a storage bucket made public
for a quick test, a security group opened to 0.0.0.0/0 during an incident,
an unencrypted volume created before the policy existed. Individually trivial;
collectively the source of most cloud security findings.
Scanning for these after deployment means finding them once they are already running. By then fixing them requires a change window, an owner who may have moved teams, and a conversation about risk tolerance.
How it works
Check the plan, not the deployed estate. Terraform's plan output describes exactly what is about to change, in a machine-readable form, before anything is created. That is the cheapest possible moment to catch a problem — the author still has the context loaded.
Policy as code, not as a wiki page. Rules are written in Rego and version controlled, so a policy change goes through review like any other change, and the history of why a rule exists stays attached to it.
Severity that means something. Findings are graded so a build can fail on critical issues while merely reporting on lower-severity ones. A gate that blocks on everything gets switched off within a fortnight.
Documented exceptions. Some violations are deliberate. Exceptions are declared in the repository with an owner and an expiry rather than by silencing a rule globally, so a temporary allowance does not quietly become permanent.
Output built for a human. Each finding names the resource, the rule, why it matters, and the change that resolves it. A scanner that emits a resource ID and a rule number gets ignored.
Why it matters
This is the shift-left argument applied to infrastructure: the same misconfiguration costs minutes in review and considerably more once it is live and holding data.
It also produces the artifact compliance teams actually ask for — a version-controlled record of what the rules were, when they changed, and which exceptions were granted to whom. That evidence is usually reconstructed by hand ahead of an audit; here it is a byproduct of the pipeline.