Read it anyway, pick out anything that could be real, and reply with a short, courteous request for impact and proof. Most scanner dumps are noise, but a few contain a true finding. A polite answer costs little and protects your reputation with people who report well.
Why these reports exist
OWASP warns that organizations running public programs should expect a large number of junk or false positive reports, including people running automated tools they do not understand. Some reporters send raw output in hope of a reward. Others are beginners who do not know what a useful report looks like. Both deserve a reply, though not necessarily a long one.
A five minute check
- Scan for severity words such as remote code execution, authentication bypass or data exposure. Ignore generic labels.
- Look for findings you can verify in one request. An exposed admin page or an open storage bucket is easy to confirm.
- Compare against your known accepted items. Missing headers, version banners and similar low value items may be excluded in your policy.
- Check the target. Is it one of your assets, and is it in scope?
- Decide: reply with a question, reply with thanks and a closure, or escalate.
Reply patterns
| Report quality | Reply |
|---|---|
| Contains one real, verifiable finding | Thank them, confirm that one item, and say you will handle it as a normal report |
| Contains plausible items with no proof | Ask for the request and response that shows impact, and what an attacker gains |
| Entirely generic, known excluded items | Thank them, point to the excluded list in your policy, and close |
| Demands payment before details | See what to do when a reporter asks for payment |
What to ask for
Use specific words. "Please send the exact request and response that show the issue, the account you used, and what data or action an attacker would gain." A good reporter can answer in minutes. A tool dump submitter often cannot, and that settles the case without argument.
OWASP's guidance says a useful initial report includes enough detail to understand and reproduce the issue, supporting evidence such as HTTP requests and responses, proof of concept if available, and the impact. You can paste those points into your reply.
What to avoid
- Sarcasm or a lecture. Public replies get screenshots.
- Promises of reward for low-value items.
- Ignoring the whole thing without checking, because a real flaw can hide among noise.
- Putting the researcher on a block list on the first report.
Reduce the volume before it starts
Write your excluded findings plainly in your policy. Provide a short report template. If your product depends on open source packages, run your own dependency scan first so that known issues are not reported back to you as discoveries. Safeguard's SBOM and dependency scanning can do that, and a free scan takes a few minutes. The same logic applies before a bounty launch: see fixing scanner-findable bugs first.
Quick check
Do I owe a reply to every dump?
A short reply is good practice. It teaches reporters what you want and shows you are listening.
Could an AI have written the report?
Possibly. Judge the content, not the author. See what your policy can say about AI-written reports.
Sources
Last reviewed: 19 October 2026.
