A good security bug report has four parts: a short summary, the technical details, a minimal proof of concept and the impact. GitHub's default private reporting form asks for exactly those. Add exact steps, the environment and the expected result, and a developer can reproduce and judge it quickly.
Start from a proven form
GitHub's documentation for privately reporting a vulnerability says the form by default asks for a summary, details, a proof of concept and an impact statement, and that you should include enough detail for maintainers to reproduce and assess the issue. Maintainers can customize the form and require other information.
You do not need GitHub to use the structure. Copy it into your own ticket template.
The template
- Title. Neutral and specific: "Export endpoint returns another tenant's file when the ID is changed".
- Summary. Two sentences on what is wrong.
- Affected version, build and environment. Include browser, device or API client where relevant.
- Preconditions. Which account, role or setting is required.
- Steps to reproduce. Numbered, one action each.
- Expected result and actual result.
- Proof of concept. The smallest request, input or file that shows the problem.
- Impact. What an attacker gains, in plain terms.
- Suggested severity, with a reason. Mark it as a suggestion.
- Evidence. Logs and screenshots with real data redacted.
What each part is for
| Part | Question it answers |
|---|---|
| Summary | Do I need to look at this now? |
| Preconditions | Can I set up the same state? |
| Steps | Can I see it myself? |
| Proof of concept | Is the trigger exactly this? |
| Impact | How urgent is it compared with other work? |
| Evidence | What did you actually observe? |
Keep the proof of concept small
A proof of concept should show the flaw, nothing more. A single request with a changed identifier beats a script that dumps a database. Smaller is safer to store, easier to read and quicker to turn into a regression test.
Do not test with real customer accounts. Use two test accounts you control. Do not go further than you need to prove the point, and stop once access to data is demonstrated.
Report severity carefully
State what you saw, then give your suggested rating. Say who the attacker must be and what they need, such as a logged in user, or an unauthenticated visitor. A reporter who writes "critical" with no reasoning forces the developer to start from scratch. A reporter who writes "high, because any authenticated user can read any invoice" gives them a head start.
Send it to the right place
Security reports belong in a private channel, not the public backlog. If the project has private reporting enabled, GitHub says the maintainers are notified when you submit and that you are added as a collaborator and credited user on the proposed advisory. If the repository has not enabled it, follow the project's security policy.
After the fix
Offer to retest. Rerun your steps on the fixed build, confirm the proof of concept no longer works, and try close variations, such as other endpoints with the same pattern. Then add the case to the regression suite.
Try it yourself
Click through it at your own pace, or open it full screen. Watch which facts decide whether a finding is exploitable, and make sure your reports carry the same facts.
Safeguard's free scan gives dependency findings with context on reachability, which saves reporters from filing issues that cannot be triggered.
Quick check
Should a report include an exploit script?
Only the smallest proof of concept needed to show the flaw. Avoid anything that extracts real data or works as a ready made attack tool.
Do I need to calculate a CVSS score?
Not always. A reasoned suggested severity helps, and the security team can calculate the formal score.
Sources
Last reviewed: 19 October 2026.
