How do you find every live Checkov suppression across your Terraform repos, and spot the stale ones?

## Why this is an inventory problem at all A suppression is written once, by one person, under deadline, and then it is permanent and unattended. No report tells you it aged. No scan tells you the reason stopped being true. Over a few years an estate accumulates a large, unowned set of decisions that are individually defensible and collectively unknown. Enumerating them is the only way anyone finds out what the gate is actually enforcing versus what it is configured to enforce. ## Source one: the annotations A repository-wide search for the annotation form (`checkov:skip=`) gets you every inline suppression in the source. This part is easy and people stop here. What the raw grep does not give you is whether each one still does anything. A skip only has an effect if the check it names would otherwise fire on that block. Change the resource so it is compliant, and the annotation stays behind, suppressing nothing while telling every future reader that a risk was considered and accepted here. That is worse than no comment, because it is a false statement about the security posture of the code. ## Source two: the invisible skips This is the half that gets missed, and it is the half with the widest blast radius: - `skip-check` lists in `.checkov.yaml` — a rule disabled across an entire repository, with no field for a reason and nothing at any violating line. - `skip-path` patterns — whole directories removed from the scan. These are the hardest to find by inspection, because an excluded path produces **no finding and no skip record**. Nothing in the output shows the code was never looked at; you can only find it by reading the pattern. - Skip flags passed on the command line inside the pipeline definition, which live in a CI file that nobody thinks of as security configuration. An inventory that does not read all three of these under-reports, and it under-reports precisely where the exposure is largest. ## Source three: the scan's own output The authoritative view is the scanner telling you what it skipped. Run the scan across the estate and read the skipped section of the machine-readable output — it yields one structured record per suppressed check, carrying the file, the resource, the check id and the suppression comment. That is directly joinable into a single table across every repository, and it is the artifact you actually want: repo, path, resource, check id, reason. It has one more property that grep lacks: a suppression that appears in the skipped section is one that matched a real finding. Annotations present in source but absent from that section are inert. ## Ageing the list Git supplies the metadata the annotation does not carry. `git blame` on the skip line gives the commit, the author and the date; the commit message and the pull request give the change it was introduced with. From that you can build the columns that matter for triage: how old, who added it, and whether the change it accompanied is still relevant. ## What stale looks like Several distinct signals, and they call for different actions: - **Inert.** The annotation matches no finding — the resource was fixed, or the check id was renamed or removed. Delete it. An id that matches nothing produces no error and no warning, so these accumulate quietly. - **Aged intent.** A reason saying "temporary" or "until the migration lands", dated years ago. The migration either landed or was abandoned; either way the stated condition is resolvable by asking one person. - **Dead reference.** The reason names a ticket that is closed, or a system that was decommissioned. - **Orphaned.** The author has left, and no team claims the resource. This is an ownership problem before it is a security one. - **Propagated.** The same reason string appears verbatim across many repositories. That is copy-paste: a shared module, a repository template, or a widely-copied example carried the annotation outward. The receiving teams never evaluated it and usually do not know it is there. The fix is upstream — either the module should stop producing the violating configuration, or the exemption should exist once, where someone owns it, rather than in fifty places where nobody does. ## Turning it into something that stays true The inventory is only worth building once if it is rebuilt. In practice that means running the collection on a schedule and diffing it: new suppressions since last time is a short, reviewable list, where the full set is not. And it means fixing the metadata problem at the source — if an exemption needs an owner and a date to be triageable later, a free-text comment cannot carry either, and that argues for keeping the exemption somewhere that can.