Suppressing a Finding

## The premise: the reason is a claim, not evidence The free-text reason on a suppression is written by the person who was blocked, is validated by nothing, and is read by one reviewer under time pressure. It is the weakest control in the pipeline, and it is also the last one. So the reviewer's job is not to read the reason and feel reassured; it is to work out what the reason would have to be true for, and whether any of that is checkable. ## Four questions, in order ### 1. Is the finding real? This is the fork that decides everything downstream, and it is the one candidates skip. - **The finding is true and the risk is accepted.** The resource does grant the wildcard, and there is a reason it must. A suppression is the right shape of answer; the argument is now about scope and duration. - **The finding is a false positive.** The check misreads a pattern that is actually safe here — and, crucially, is probably safe everywhere it appears. Then a per-resource skip is not a fix, it is a workaround that hides a rule bug. Every other team hits the same misfire, each writes their own skip with their own wording, and the estate accumulates dozens of annotations that all mean "the rule is wrong". The remedy is to narrow or correct the rule so nobody needs the skip. Asking "is this a rule bug or an accepted risk?" is the single highest-signal thing a reviewer can say here. ### 2. Is this the narrowest instrument? An inline annotation on the one violating block is the narrowest exemption available: one resource, one check id, visible at the site, gone when the resource is gone. If the diff instead adds an entry to the scan configuration that disables the check everywhere, or excludes a directory from scanning, the review bar is much higher — those excuse every future violation as well as this one, and leave nothing at the violating line for the next reader. ### 3. Is the reason checkable in this diff? Sort reasons into two piles. **Checkable here:** "the role is constrained by the permissions boundary attached three lines down", "this resource is destroyed by the same module's teardown", "see INFRA-4412" where the ticket is real and open. You can verify some or all of it without leaving the review. **Unfalsifiable:** "this is safe", "needed for the deploy to work", "temporary", "agreed with security". None of these can be checked, and two of them are actively misleading. "Temporary" is the one to challenge by name: an annotation has no expiry field, nothing re-evaluates it, and no report will ever say it has aged. In practice "temporary" means "permanent until somebody greps for it". "Agreed with security" is worth a single question — with whom, and where is that written — because if the agreement is real it can be pointed at, and if it cannot be pointed at, it is a claim about an absent third party. The practical ask is small: make the reason specific enough that a stranger reading it in two years can decide whether it still holds. That is the entire test, and it costs the author one sentence. ### 4. Who else inherits this line? Suppressions propagate by copy-paste better than almost anything else in a repository. A skip inside a shared Terraform module is delivered to every consumer of that module. A skip in a repository template is delivered to every repository created from it. A skip in the team's most-copied example file is delivered wherever people copy from. In all three cases the receiving team never made the judgment, never read the reason, and often does not know the line is there. So the reviewer question is: would I accept this line if it appeared, unexplained, in ten other repositories? If the answer is no, the exemption needs to be attached to something narrower than a shared file, or the module needs to stop producing the violation in the first place. ## Where the review ends There are only three outcomes worth writing down. **Approve** — the finding is real, the exemption is narrow, and the reason is specific and checkable. **Send back for a narrower form** — the mechanism is too wide, or the reason is unfalsifiable and can easily be made concrete. **Reject and ask for the fix** — the violation is straightforwardly fixable, and the skip exists because fixing it was slower than annotating it at five in the afternoon. One boundary to state rather than blur: if what this exemption genuinely needs is a named owner, an approver and a date on which it lapses, then a comment cannot carry any of that. That is a different instrument, and reaching for it is the honest answer when the risk is real but the acceptance should not be permanent or self-service.