A Report Should Remove Guesswork
A good vulnerability report removes guesswork for the triager. It should explain what is vulnerable, who can exploit it, what security boundary is crossed, what impact is possible, and how to reproduce the issue. If the reader has to infer the vulnerable condition from screenshots alone, the report is too weak.
I structure reports around reproducibility. The report should include affected version, role or account type, configuration assumptions, exact steps, relevant requests, expected result, actual result, and impact. This makes the issue easier to validate and reduces back-and-forth.
Impact Needs A Boundary
Impact is not a label. Saying XSS, IDOR, SSRF, or command injection is not enough. The report should state what the attacker gains that should not be possible. Can they read another user's data? Can they act as an administrator? Can they reach internal services? Can they execute code in a privileged context? Can they modify security settings?
When impact is limited, I say so. Accurate impact is more persuasive than exaggerated impact. A clear medium-severity report is stronger than a high-severity claim that the evidence does not support.
Evidence Should Be Minimal But Complete
Evidence should prove the issue without creating unnecessary noise. For web findings, a minimal HTTP request and response is often better than many screenshots. For code findings, the vulnerable path and attacker-controlled input are more important than a large diff. For chain findings, each step should show the state change that enables the next step.
Screenshots can help, but they should support the report rather than replace technical proof. The most valuable evidence is the part that another person can reproduce.
Root Cause And Fix Direction
Reports become more useful when they identify root cause. Missing authorization, unsafe output handling, incomplete path normalization, weak URL validation, trusted client-side state, or unsafe deserialization all require different fixes. Without root cause, the patch may block one payload and leave the vulnerable design in place.
I do not need to write the final patch, but I try to describe the control that failed and where it should be enforced. This helps engineering teams fix the class of issue instead of only the proof-of-concept.
Tone And Follow-Up
A report is technical communication. Clear language, reproducible steps, and accurate claims make the process smoother. If a triager asks for clarification, I respond with focused evidence, not a larger payload dump. If the vendor finds a configuration condition, I update the report to reflect it.
The goal is to get the issue understood and fixed. A strong report is professional, precise, and easy to verify.