Chapter 5 of 14 · Weeks 2–4
Triaging scanner output without drowning devs
- The scanner found hundreds of issues. Where do I start?
- Should I send every finding to the developers?
- How do I deal with false positives?
The first time you run a scanner across a real codebase, the number of findings will be large. That number is not a measure of risk. It is a measure of how many patterns the tool matched. Your value is in what you do between the scanner and the developer.
Sort before you send
- Group duplicates. One vulnerable library used in thirty places is one finding with thirty locations.
- Drop what does not apply. Test code, dead code and unreachable paths go to a separate list, not to developers.
- Rank what is left by exposure and impact: internet-facing beats internal, sensitive data beats none.
- Check for known exploitation. A flaw listed in a public catalogue of exploited vulnerabilities moves to the top.
- Confirm the top few by hand before you send them.
Only then open tickets, and only for the items you would defend in a meeting. A developer who gets three accurate findings will fix them. A developer who gets three hundred mixed with noise will learn to ignore the source.
False positives
Every scanner produces them. Treat each one as a tuning job, not an embarrassment. Suppress it with a written reason that names who decided and when, so the next person does not re-raise it. If a rule produces mostly noise, turn it off and note why.
The question you might not ask out loud
Am I hiding risk if I do not send every finding?
No, as long as you keep the full list and can explain how you sorted it. Sending everything is not thoroughness. It moves the triage work to the people least equipped to do it and hides the real problems in the pile.
Make fixing easy
- Say where the problem is, why it matters here and what the fix looks like.
- Link to the exact line and, if you can, a sample patch.
- Agree a fix-by date with the team, based on severity and exposure.
- Close the loop. When a fix ships, say thank you where the team can see it.
Rule of thumb:Track the size of your untriaged pile separately from the developers’ backlog. The first is your work. The second is theirs. Mixing them makes both look worse than they are.
Over the first month, keep notes on which rules and which tools produce the findings developers actually fix. That record tells you where to tune, which checks to keep and which to retire, and it gives you something concrete to show when someone asks why you did not forward everything.