To review a suppression change in a pull request, check seven things: the reason is on the allowed list, evidence is linked, the scope is narrow, an end date exists, an owner is named, the author is not the only approver, and the finding is real and current. If any is missing, request changes.
Why suppression diffs deserve their own review
A diff that adds three lines to an ignore file looks harmless. It can switch off a control for a whole service. Reviewers who would debate a variable name for ten minutes often approve these in ten seconds.
Treat the suppression file like a permissions file. Small changes, large effect.
The seven item checklist
- Reason. Is it one of the allowed reasons? "Not needed" and "false positive" with no detail do not count.
- Evidence. Is there a link or a note a stranger could follow? A pull request description with a search result is enough.
- Scope. Does the rule name one advisory, one package, one version? Be suspicious of wildcards.
- End date. Is there one, and is it within the policy maximum?
- Owner. Is a person or team named, not a bot?
- Independence. Did someone other than the code owner approve? Our post on self approval explains the risk.
- Currency. Does the finding still appear in a fresh scan? If not, the suppression may be dead weight, and the right change is to delete it.
Quick signals in the diff
| In the diff | What to ask |
|---|---|
| A new wildcard or package wide rule | Why not one advisory? |
| An end date more than a year out | What justifies it? |
| An edited end date on an old entry | Is there new evidence, or only delay? |
| Removed comments or reasons | Why was context deleted? |
| Many entries added at once | Was a baseline intended, and approved as such? |
Automate the boring parts
A CI job can fail the pull request when an entry has no reason, no end date or no owner. That frees human reviewers for the judgment calls: is the evidence convincing, and is the scope right. See policy exceptions in code.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a pull request is blocked until the finding is fixed or a recorded exception covers it.
A worked example
A pull request adds one entry: advisory ID, package, version, reason not in execute path, a link to a code search, an owner, and an end date 90 days out. The reviewer opens the link, runs the search, and finds no call. Approval takes four minutes. Compare a pull request that adds a package wide wildcard with the note "noisy". That one gets changes requested, politely, with the checklist pasted in.
Keep the template short
Seven items is already near the limit people will actually read. If you add more, move some into automated checks.
Quick check
Who should approve a suppression change?
Someone other than the author or code owner, ideally from security or a peer team.
Should the checklist live in the pull request template?
Yes. A template line item that appears only when the ignore file changes keeps it visible without adding noise elsewhere.
Last reviewed: 19 October 2026.
