Group findings by rule and root cause. Post one comment on the first occurrence that explains the pattern, shows the count, and lists the other locations. The author fixes the pattern once instead of answering twelve threads that say the same thing.
When grouping makes sense
A rename of a helper, a copy pasted query builder or an upgraded library can produce the same finding in many places. Twelve inline comments with the same text feel like spam, even though each is technically correct.
Grouping fits when findings share all three of these: the same rule, the same fix, and the same author intent. If any differ, keep them separate.
The shape of a grouped comment
Unescaped input in 12 SQL calls (same pattern)
First occurrence: orders/search.py, line 42.
Also in: orders/export.py (3), reports/daily.py (5), api/lookup.py (3).
Fix: switch these calls to the parameterised helper. The suggested
change on this line shows the pattern.
Full list is in the check summary.
Notice the structure: pattern, count, first location, other files with counts, one fix, a link to the full list.
What to avoid
- Hiding the locations. Grouping should shorten the text, not remove information.
- Grouping across different severities. A critical item buried in a group of lows gets lost.
- Grouping across files owned by different teams without noting the owners.
| Approach | Developer effort | Risk |
|---|---|---|
| One thread per hit | High, repetitive | Fatigue, partial fixes |
| One grouped comment, full list in summary | Low | Low, if locations listed |
| Count only, no locations | Lowest | High, nothing actionable |
Tie grouping to ownership
In a repository with CODEOWNERS, files map to owners. Where a grouped finding spans several owners, list them in the comment so the right people see it. GitHub requests code owners for review automatically when their files change, and the last matching pattern takes precedence, so check your file order when owners seem wrong.
Review the grouped comment the way a developer would. If you cannot tell in ten seconds what to change and where, the grouping has gone too far and needs more detail.
Keep a stable identity per group
Make the group key stable between pushes: rule id plus a short root cause label. If the key shifts on each run, the bot will post a new comment each push and the benefit disappears. Our post on duplicate alerts and partial fingerprints explains why this happens in scan output.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for findings that share a rule and decide which you would group.
Safeguard code and dependency scanning reports findings with file and line detail, which makes grouping by rule straightforward. A free scan shows the format.
Quick check
Does grouping hide issues from auditors?
Not if the full list stays in the check summary or scan record. The comment is a view, and the record is complete.
How many hits justify a group?
Three or more with the same fix is a common threshold. Tune it to your team.
Sources
Last reviewed: 19 October 2026.
