A report should let another engineer reproduce the result without reconstructing your entire investigation. Lead with the affected behavior, then show the smallest sequence that demonstrates it.
Separate tested impact from plausible extensions. If only one synthetic report was readable, explain that evidence precisely and identify wider exposure as an open question.
Before you start
- A confirmed observation, the affected version or component and the expected security rule.
- Minimal sanitized requests, response excerpts and the synthetic identities used.
- The proposed remediation, any known limitations and a way to remove test data.
Follow the steps
- Write a title that names the operation and failed boundary, such as a cross-tenant report read.
- List prerequisites before steps: account roles, object ownership, feature settings and relevant version.
- Number the exact requests or actions. State the expected and observed result at the step where the boundary fails.
- Explain impact using the actual data and action demonstrated. Keep severity reasoning separate from unsupported worst-case claims.
- Add a remediation direction, a regression test and cleanup instructions. Retest using a fresh session after the fix.
Use a precise prompt
Adapt to your evidence
Draft a finding from this confirmed synthetic-account test. Include a precise title, prerequisites, numbered reproduction steps, expected versus observed behavior, evidence references, demonstrated impact and a retest plan. Flag missing information instead of filling it in. Keep untested extensions outside the impact statement.
Verify your work
- A second reader can follow the steps with fresh synthetic identities and obtain the same result.
- Every screenshot or excerpt supports a specific statement and excludes unrelated sensitive data.
- The retest covers the original failure and valid behavior; cleanup removes only the test objects you created.
Bring your own evidence into a conversation and work through the next question.
Open chat