A suppression comment that survives review states four things: which rule it silences, why the flagged code is safe, what evidence supports that claim, and who will recheck it and when. A bare "ignore" or "false positive" tells the next reader nothing and tends to hide real bugs.
Why the comment matters more than the suppression
Silencing a finding is a decision. The code that carries it will outlive the person who made it. Six months later a reviewer, an auditor or a new teammate sees a suppression and has to guess whether anyone thought about it.
The SARIF standard, which many scanners use for output, treats this as a first class idea. A suppression object can carry a justification property, described in the spec as a user supplied string that explains why the result was suppressed. The spec notes that this information is commonly available in existing suppression mechanisms, so the habit of explaining is already built into the tooling. Use it.
A template that works
Keep it to one or two lines next to the code, in whatever syntax your scanner supports. Include:
| Field | Example content |
|---|---|
| Rule | The rule name or ID being silenced |
| Reason | Why this instance is not exploitable, in one sentence |
| Evidence | A test, design note or ticket number that shows it |
| Owner | A team or person, not "security" |
| Review by | A date, usually 90 to 180 days out |
A filled in example might read: rule sql-injection, reason "table name comes from a hard coded enum, never from a request", evidence "unit test TableNameTest and ticket APP-412", owner payments team, review by 2027-01-31.
What a reviewer should reject
- A suppression with no reason.
- A reason that says only "false positive" without saying what makes it false.
- A suppression covering a whole file or directory when one line was flagged.
- A reason that depends on a control elsewhere, with no link to that control.
- Suppressions added in the same pull request as the vulnerable code, with no second person looking.
Steps to adopt this in a team
- Write the template into your contributing guide.
- Add a pull request check that fails when a suppression marker has no reason text. A simple search over the diff is enough to begin with.
- Make code owners for security sensitive paths approve any new suppression there.
- Once a quarter, list all suppressions past their review date and either renew them with fresh evidence or delete them.
Step 4 is the one teams skip, and it is the one that stops suppressions from turning into a permanent blind spot. See also how to tune or suppress a noisy alert for the earlier decision of whether to suppress at all.
One factual note on Safeguard
Safeguard supports policies and gates that can enforce rules like these on pull requests. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
Is it enough to write "false positive" as the reason?
No. Say what makes it false: for example, that the input is a constant, or that a validation step upstream removes the dangerous characters. The reason should let a stranger verify the claim.
How long should a suppression last?
There is no standard number. Many teams choose 90 to 180 days and renew only with fresh evidence. The point is that every suppression gets looked at again.
Sources
- SARIF 2.1.0 specification, OASIS, sections on the suppression object and justification property.
Last reviewed: 19 October 2026.
