Developers should own fixing findings in their code, and security should own the rules, severity policy and the hard calls. A split model works best: developers do first-pass triage on pull request findings, and a small security group handles the backlog and disputes. Pure central triage does not scale.
Why this question decides success
A static analysis tool produces findings. Someone has to decide which are real. OWASP notes that these tools produce many false positives and that it is hard to prove a reported issue is a real vulnerability. That means triage is not optional overhead. It is the main running cost of the tool.
Model 1: central security team triages everything
Pros: consistent decisions, one place to learn from patterns, developers are not interrupted.
Cons: the team becomes a bottleneck, lacks code context and often asks developers anyway. It works for a handful of repositories and breaks beyond that.
Model 2: developers triage their own findings
Pros: the author knows the code and can tell quickly whether a flow is reachable. Fixes happen in the same pull request.
Cons: developers vary in security knowledge, suppress to get unblocked, and are not rewarded for careful triage. Without guardrails, results get quieter without getting safer.
Model 3: a split with clear rules
This is the one most teams settle on.
- Pull request findings: the author decides fix or dismiss, with a required reason from a short list.
- Dismissals of high severity findings: reviewed by a named security reviewer within an agreed time.
- Backlog from scheduled scans: security samples and groups by rule, then hands clusters to owning teams.
- Rules and thresholds: owned by security, changed through a lightweight review.
Make triage cheap
Whichever model you pick, reduce the cost per finding.
- Show the data flow and the line, not a paragraph of theory.
- Offer standard dismissal reasons: test code, unreachable, sanitized elsewhere, accepted risk.
- Record who dismissed what and why. The record is useful in audits and for rule tuning.
- Turn off rules that are wrong in your environment instead of dismissing the same finding hundreds of times.
Start small
Do not try to define the whole process at once. Pick two repositories, name a security reviewer and one developer lead for each, and run the split model for a month. Write down what went wrong: findings nobody picked up, disputes about severity, reasons that did not fit your list. Adjust the rules, then widen to more repositories. A process refined on two teams survives contact with twenty far better than one designed in a meeting room.
Measure it
Track time to first triage, share of findings dismissed as not real by rule, and age of open high severity items. A rule dismissed as not real nine times out of ten is a candidate for tuning or removal.
Policy gates can help here. Safeguard supports policies and gates that can require a reason or reviewer before certain findings are waived.
Quick check
Should developers be allowed to dismiss findings?
Yes for low risk items with a required reason. Route high severity dismissals to a security reviewer.
What is the best sign triage is failing?
Findings aging without owners, or the same rule being dismissed repeatedly without anyone tuning it.
Sources
Last reviewed: 19 October 2026.
