There is no fixed number, but a good rule is a small cap, around five inline comments per pull request, only for new findings on changed lines, with everything else in one summary comment. When comments pile up, developers start ignoring all of them.
Why volume matters
A pull request is where a developer is already thinking about one change. A scanner comment competes for that attention. If most comments are noise or old issues, people learn to scroll past them, and the one real finding gets scrolled past too.
The cap is a judgement, not a standard. Choose a number by watching what your team actually reads, and adjust.
A comment policy
| Rule | Reason |
|---|---|
| Comment only on lines changed in this pull request | The author can fix it now, in context |
| Comment only on new findings, not baseline ones | Old debt is a separate stream of work |
| Inline comment only above a severity and confidence threshold | Low confidence items waste attention |
| Cap inline comments, put the rest in a summary | Keeps the thread readable |
| One comment per root cause, not per instance | A repeated pattern needs one explanation |
| Every comment says what is wrong, why it matters, and how to fix it | Actionable beats alarming |
What a good comment contains
- The rule name in plain words.
- The risky line and what untrusted input reaches it.
- A one or two line fix, ideally a code suggestion.
- A link to a short explanation, and a way to mark it as a false positive with a reason.
Compare "Possible SQL injection (CWE-89)" with "User supplied id reaches this query without parameter binding. Use a bound parameter as shown. Mark as false positive if the id is validated upstream and say how." The second can be acted on in a minute.
Block, warn or inform
Decide per rule whether a finding blocks the merge, warns or only informs. Blocking should be rare and limited to rules you trust, as discussed in block or warn on pull requests. Everything else can post once and stay quiet.
Measure the experience
Track how many comments are resolved by a code change, how many are dismissed, and how quickly. If most comments are dismissed, the rule or threshold is wrong. A short developer survey helps too, see five questions for a SAST pilot survey.
Try it yourself
Open the demo and see how a gate reports the result on a pull request.
Click through it at your own pace, or open it full screen.
One factual note on Safeguard
Safeguard offers policies and gates 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
Should low severity findings ever appear on a pull request?
Usually in a summary only. Inline comments are best kept for findings the author is likely to fix right now.
What if the scanner finds a real issue outside the changed lines?
Send it to the backlog with an owner. It is real, but it is not this pull request's job to fix.
Last reviewed: 19 October 2026.
