Writing reports that get paid

Impact-first titles, copy-pasteable PoCs, and how to handle triage replies calmly.

8 min read

A great bug with a poor report gets closed as informative or paid a fraction of its worth. The report *is* the product you’re selling.

The anatomy of a strong report

Title — impact-first: “Reflected XSS on app.target.com leads to session theft”, not “XSS found”.
Summary — 2–3 sentences: what, where, why it matters.
Steps to reproduce — numbered, copy-pasteable, with exact requests.
Proof of concept — the request/response that demonstrates it, not just a screenshot.
Business impact — the realistic worst case, in the company’s terms.
Severity — a CVSS vector you can defend.

Demonstrate *impact*, not just presence. A reflected payload isn’t XSS until it executes; an exposed endpoint isn’t a bug until you show what it leaks.

Handling triage replies

You’ll get pushback — “duplicate”, “can’t reproduce”, “out of scope”, “lowering severity”. Respond like a professional:

Acknowledge their position calmly.
Give the single most decisive *new* piece of evidence.
End with one specific ask.
Never CVSS-spam, never threaten public disclosure, and give them a working day to respond.