A security bug report is actionable when it names the product and version, gives a minimal reproduction, states the impact in plain words, and says how you will handle disclosure. Send it to the channel the vendor publishes, keep proof of concept safe, and avoid demands or threats.
Find the right door first
Look for a security contact before writing. Many organisations publish one in a disclosure policy page or a security.txt file. Using the published channel gets the report to people who know what to do with it. If you cannot find one, a general security address or a direct maintainer contact is the next option. Do not post the details publicly first.
What to include
| Field | What to write |
|---|---|
| Summary | One sentence: the flaw and where it lives |
| Affected | Product, version or commit, and configuration |
| Steps | Numbered, minimal, tested on a clean setup |
| Impact | What an attacker can do and under which conditions |
| Evidence | Request and response, log lines, short video if useful |
| Suggested fix | Optional, labelled as a suggestion |
| Your details | How to reach you, and whether you want credit |
| Timeline | Your intended disclosure timing, stated politely |
Short and complete beats long and loose. A triager will try your steps. If they fail on the first attempt, your report moves to the bottom.
Write the impact honestly
State what you demonstrated, then what you think is possible, and mark which is which. "I read another user's order by changing the id" is demonstrated. "This may allow reading all orders" is a hypothesis unless you tested it. Overstating impact costs credibility, and understating it can lead to slow triage.
Handle data with care
Test with your own accounts and data where you can. If you touch real user data by accident, stop, say so in the report, and delete what you collected. Do not go further than needed to prove the issue. Do not run tests that could degrade a service.
Be clear about timelines
Coordinated disclosure policies often state a fixed window before publication, and the length varies by policy. Read the vendor's policy and follow it if it states a timeline. If there is none, propose one and be willing to extend it when the vendor is making progress.
After you send it
Expect an acknowledgement within a few days. If you hear nothing, follow up once, politely, after a week or so. Avoid threats and do not ask for payment as a condition of reporting. Keep your own records of what you sent and when.
For the vendor reading this
A good report makes your triage easy, and you can make reporters' lives easier too by publishing a clear policy, a safe harbor statement and a contact. Reports that arrive through a clean channel are cheaper to handle than ones that arrive on social media.
Safeguard offers zero-day discovery and dependency scanning. You can try the free scan at gold.safeguard.sh/scan to check your own dependencies before a researcher does.
Quick check
Should I include a working exploit?
Include the minimum needed to reproduce the issue safely. A proof of concept that shows the flaw is enough.
What if the vendor does not answer?
Follow up once, then consider a coordinator or the policy's stated escalation path before any public step.
Sources
Last reviewed: 19 October 2026.
