Do not try to fix them all. Save the result as a baseline, sample a few findings to estimate how many are real, group the rest by type, fix the high severity and reachable ones first, and set the pull request gate to block only new issues. A big first number is common and not a verdict.
Why the number is large
OWASP lists many false positives among static analysis weaknesses, and notes that confirming a flagged issue is real can be hard. Add years of legacy code and default rules that are broad, and a large first count is expected.
Step by step
- Freeze the number. Record the scan as the baseline. Everything on it is legacy debt. New findings are new work.
- Sample. Pick twenty findings across severities and review each by hand. Count real, false and unclear. This gives you a rough false positive rate for your codebase.
- Group. Cluster by rule or weakness type. Often a few rules produce most of the volume.
- Tune. Disable or downgrade rules that are mostly false in your sample. Write down why.
- Rank. Prioritize by severity, whether the code is reachable from outside, and whether sensitive data is involved.
- Assign. Give each top group an owner and a target sprint.
- Gate. Block merges on new high confidence findings only.
Triage table
| Finding looks like | Likely action |
|---|---|
| Injection on a path from a public endpoint | Fix now |
| Weak hash in a test helper | Suppress with reason |
| Hardcoded secret | Rotate first, then remove |
| Style or low severity noise | Defer, review rule setting |
| Same issue in many files | Fix at the shared helper |
Keep the suppressions honest
Every suppression needs a reason, an owner and a review date. Undated suppressions turn into permanent blind spots.
Common mistakes
Avoid two opposite errors. One is declaring bankruptcy and turning the tool off because the number is scary. The other is assigning all thousand to developers, who will then ignore the whole list. Report progress on the groups you chose, not on the total. A weekly note such as new findings blocked, legacy groups closed and rules tuned shows movement without drowning anyone, and it gives leadership a number that goes down for good reasons.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a few findings and decide for each whether you would fix, suppress or defer.
Quick check
Is a high count a sign the code is terrible?
Not by itself. Counts depend on rule sets, code size and noise.
Should we switch tools if there are many false positives?
Try tuning first. Switch only if tuning cannot bring the noise to a level developers will read.
Where Safeguard fits
Safeguard provides reachability analysis and policy gates for dependency findings, which helps rank what to fix first. Run the free scan to see it.
Sources
Last reviewed: 19 October 2026.
