Hide or lock the issue right away, thank the reporter, and move the conversation to a private channel. Then assume the details may have been seen, work out whether the flaw is real, and change your issue template so the next reporter finds the private route first.
Why it happens
People post in public trackers when they cannot find a private route. OWASP's disclosure guidance lists existing issue trackers among the places researchers try when no policy is visible, and recommends providing dedicated instructions for reporting security issues on a tracker, using specific categories or marking issues confidential. If you have neither, public reports are expected.
The first ten minutes
| Step | Action |
|---|---|
| 1 | Hide, lock or convert the issue to a private report, if your platform allows it |
| 2 | Save a copy of the original text for the case file |
| 3 | Post a short neutral note asking for follow up by the private route |
| 4 | Write to the reporter privately if you have contact details |
| 5 | Open a case and follow the 24 hour triage routine |
Keep the public note free of detail. Something like "Thanks for flagging this. We have moved the discussion to a private channel" is enough. Do not confirm or deny the flaw publicly in the first message.
Assume it was seen
Hiding an issue does not erase email notifications, web archives, forks, mirrors or what other watchers copied. Plan as if the details are public. That changes your priorities. Reproduce quickly, assess exposure, and decide how fast a fix is needed. Prepare a short advisory in case the issue spreads, as described in what goes in a security advisory.
OWASP notes that once a patch is released, attackers can reverse engineer the vulnerability anyway, so the window between disclosure and a fix is what you can still shorten.
Check for use
Look at logs for signs that anyone tried the described steps. If you find real exploitation, switch to incident handling.
Fix the process
- Add a visible line to your new issue form: "Do not report security issues here" with a link to your policy and private address.
- Enable private reporting on the repository, if your platform supports it.
- Add a security policy file to the repository root and link it from the README.
- Add the policy URL to your security.txt Policy field.
- Brief your maintainers on what to do when it happens.
See security.txt and security.md for SDK repos and security.md vs security.txt.
Be kind to the reporter
Most people who post publicly are not malicious. They did not know. A friendly redirect keeps them as a future ally. A scolding drives them away, or to social media.
Safeguard note
If the public issue is about a vulnerable dependency, Safeguard's reachability analysis helps you judge whether your code is exposed, and its free scan at gold.safeguard.sh/scan can check a project quickly.
Quick check
Should we delete the issue instead of hiding it?
Hiding or locking is usually better than deleting, because you keep the evidence and the thread history for the case file. Follow your platform's options.
Do we have to tell users it was public?
That depends on severity and exposure. Decide once you understand the flaw, and cover it in your advisory.
Sources
Last reviewed: 19 October 2026.
