To get a false positive fixed, report one rule per issue with a minimal reproducible example, the tool and rule version, what you expected, and what you got. Strip secrets and customer code first. A report the maintainer can run in two minutes gets answered; a screenshot does not.
Why bother reporting
Local suppressions fix your noise. Reports fix everyone's, including your own next year. A rule that raises many false alarms is a defect in the rule, and tool makers cannot repair what they never hear about.
The ZAP project's guidance is a good model even if you use a different tool: report false positives, keep each issue to one scan rule, include enough information to reproduce the problem, and remove sensitive data before sending. The same advice says to first understand the reported issue and test it manually, so you are sure it is not real.
Checklist before you send
- Confirm it is false. Reproduce the analysis by hand. See confirming a finding for DAST and why SAST false positives happen for code.
- Reduce it. Cut the code or the request down to the smallest sample that still triggers the alert. Ten lines beats a whole repository.
- Remove anything private. Hostnames, tokens, customer data, proprietary logic. Rewrite the sample with neutral names.
- Record versions. Tool version, rule ID and rule version, ruleset, language version, and the framework involved.
- State expected and actual results. One sentence each.
- Explain why it is false. For example, "the value comes from a constant" or "the framework escapes this output".
- Say what you tried. Threshold changes, filters, or inline suppressions, so the maintainer can see the gap.
- One issue per rule. Several false alarms from several rules become several reports.
A template
| Field | Content |
|---|---|
| Title | Rule ID and a short symptom |
| Version | Tool, rule, language, framework |
| Sample | Minimal code or request, anonymised |
| Expected | No finding, because of a stated reason |
| Actual | Finding text copied from the output |
| Workaround | What you used locally |
Commercial tools and support
Paid tools usually have a support channel instead of a public tracker. The same checklist applies. Ask for a rule level fix, not only a suppression, and ask how you will be told when it ships.
Close the loop
Keep a list of reported false positives with links. When the fix ships, remove your local workaround, otherwise you will carry a stale suppression indefinitely. See reviewing suppressions on a schedule.
One factual note on Safeguard
Safeguard offers policies and reachability analysis that can help reduce noise on your side while a report is pending. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
Is it safe to share code with a vendor?
Share only a reduced sample you have anonymised. Check your contract and policy first.
What if I cannot reduce the sample?
Say so in the report and describe the code pattern in words. A pattern description is still useful to a rule author.
Sources
Last reviewed: 19 October 2026.
