When a developer says the scanner is wrong, treat it as a bug report. Ask for a short piece of evidence, reproduce the result, decide within a set time, and either fix the rule or explain why the finding stands. Respect and speed matter more than who is right.
Start from curiosity
Some reports are correct. Others come from a misread message. Either way, a defensive reply ends future reports. Open with a thank you and one question: "Can you show what makes this a false result?"
What evidence to ask for
Keep the ask small, so people actually send it.
| Evidence | Example |
|---|---|
| Where | File, line, or package and version |
| Why it is wrong | "The input is validated on line 12" or "This path is not called in production" |
| What they tried | Pointer to the rule and the version of the tool |
| Impact | Is it blocking a merge? |
A link to the finding is often enough. Do not require a formal form for a quick case.
Reproduce before deciding
- Run the same scan on the same commit with the same tool version. See why a scan may differ between laptop and CI.
- Read the rule and the code path, and check whether the claim holds.
- Ask a second person if you are unsure. Two reviewers beat one.
Decide within a stated time
Publish a target, such as one working day for a blocking item and a week for others. If a finding is blocking and not resolved by the target, offer a dated exception so the developer can ship, and keep investigating. See settle a severity dispute between security and engineering.
Three outcomes
The developer is right. Mark the finding as a false positive with the reason. Create a ticket for the rule: narrow it, add a case to the regression set, or retire it. Tell the reporter what changed. See building a regression corpus from false positive reports.
The finding is right, but low priority. Explain the risk in two sentences and offer a defer or accept with a date and an owner.
The finding is right and serious. Show the exploit path, in words, and offer help with the fix. Do not turn it into a debate about the tool.
Protect against abuse without being suspicious
A few people will mark everything as wrong to move faster. Handle it with data, not accusations. Review dismissals by team each month and ask about outliers, as in how to measure alert fatigue. Require the same evidence for everyone.
Make dismissal auditable
Every dismissal should carry a reason and a name. When an auditor or a customer asks how you treat false positives, you can show a record rather than a story. Keep the reasons short and from a list so they can be counted.
Close the loop
After each decision, reply to the developer with the outcome and the reason. If a rule was changed, link to the change note. People report more when they see results.
Safeguard offers policy controls and reachability analysis so decisions about whether a finding applies can be recorded against the code path. Try the free scan at gold.safeguard.sh/scan.
Quick check
Should the developer be able to dismiss without approval?
For low risk findings with a reason, many teams allow it. For high risk ones, require a second approver. Decide per severity and write it down.
What if we disagree about the evidence?
Bring in a neutral reviewer, apply a dated exception if it blocks work, and keep the decision on record.
Last reviewed: 19 October 2026.
