Use inline suppressions for single, well explained exceptions, because they sit beside the code and move with it. Use a central ignore file or external store for broad rules, generated code and anything auditors need to list in one place. Most mature teams use both, with clear limits on each.
The two models
The SARIF specification names them directly. A suppression of kind "inSource" is "a syntactic construct offered by the programming language", such as an annotation or a specially formatted comment. A suppression of kind "external" lives in "an external, persistent store", for example a database of historical results where a finding can be marked and later ignored if it appears again.
Those two kinds map to everyday practice: a comment in the file, or a record somewhere else.
Comparison
| Question | Inline | Central file or store |
|---|---|---|
| Does it survive a file move or refactor | Yes, it moves with the line | Often breaks if matching uses paths or line numbers |
| Easy to audit as a list | Harder, needs a search | Easy, one place |
| Visible to the developer reading the code | Yes | No, they must know to look |
| Reviewed in the same pull request | Yes | Only if the file is in the repo and covered by review |
| Good for generated or vendored code | No, you cannot edit those files | Yes |
| Good for a rule you want off everywhere | No | Yes |
| Risk of abuse | Quiet, scattered exceptions | Broad patterns that silence too much |
A practical split
- Use inline for one line, one reason. The reader of the code sees the exception and its justification together.
- Use a central file, kept in the repository and covered by code owners, for path based exclusions such as generated folders. See excluding tests, generated and vendored code.
- Use an external store, if your scanner provides one, for team wide decisions that need an approver and a history.
- Never use a central pattern to silence a rule for an entire repository without an owner and a review date.
Pitfalls to watch for
Line based matching is fragile. If a central entry says "ignore rule X at file Y line 42", an unrelated edit shifts the line and the ignore silently stops applying, or applies to the wrong code. Prefer matching on a stable fingerprint or a code pattern where your tool supports it.
Central files also grow without anyone noticing. Put the file under review, count its entries each quarter and delete lines that no longer match anything.
Inline comments tempt people to copy and paste. Require that each one carries its own reason rather than reusing a generic marker.
One factual note on Safeguard
Safeguard policies and gates can be used to set repository level rules for 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
Which one is safer by default?
Neither wins automatically. Inline is narrower, which limits blast radius. Central is more visible, which helps audit. The safer setup is inline for single cases plus a reviewed central file for broad ones.
What if we switch scanners?
Inline comments often need rewriting to the new tool's syntax. Central records may need an export and a mapping. See the guide on keeping baselines and suppressions when switching tools.
Sources
- SARIF 2.1.0 specification, OASIS, section 3.35 on suppression objects.
Last reviewed: 19 October 2026.
