A vulnerability title is not a debugging plan. Engineers need to understand what the tester observed, why it matters, and how to reproduce it without rebuilding the entire investigation.
Start with the security boundary
The clearest reports explain the boundary that failed. That might be a role check, a tenant boundary, a workflow transition, or an assumption about untrusted input. Naming the boundary connects the symptom to the control that needs to change.
Make evidence reproducible
Strong evidence includes the relevant request sequence, the observed response, the expected secure behavior, and the minimum conditions required to reproduce the issue. Sensitive values should be removed or safely redacted without hiding the mechanics of the finding.
Engineers should be able to answer three questions quickly:
- Can I reproduce this behavior?
- What could an attacker achieve?
- How will I know the fix is complete?
Retest the outcome
A patch can close one request path while leaving the underlying control inconsistent elsewhere. Retesting should verify both the original proof and nearby variants that exercise the same security boundary.
The best report is not the longest one. It is the report that helps a team move from verified risk to verified resolution with the least ambiguity.