Writing Reports That Get Paid

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: In bug bounty, you are not paid for finding a vulnerability. You are paid for communicating a vulnerability so clearly and convincingly that the company can understand it, reproduce it, grasp its impact, and fix it. The report is not paperwork that follows the work — the report is the product you sell. A brilliant finding in a poor report earns little or nothing. An equally good finding in an excellent report earns full value. This page is the craft of the report.

Part 1: The Problem

Across 5A.1–5A.3 you learned to choose programs, hunt deeply, and find what others miss. But here is the truth that newcomers underestimate most: all of that effort converts to income only through the report.

The company never watched you find the bug. They receive only your report. From that document alone, they must: understand what the vulnerability is, reproduce it themselves, assess how severe it is, and decide what to pay. If the report is unclear, they cannot reproduce it (rejected — 5A.1). If it fails to convey impact, it is rated — and paid — lower than it deserves. If it is unprofessional, it damages your reputation.

This was previewed in 2.11: “the report is the deliverable.” In bug bounty that is literally and economically true — the report is the product. This page is how to write one that gets paid.

Part 2: The Concept — What the Report Must Achieve

A bug bounty report has a specific job: get a busy triager and a busy security team, who never saw your work, to fully understand and act on your finding. To do that, every report must achieve four things:

   1. UNDERSTAND  — they grasp exactly what the vulnerability is
   2. REPRODUCE   — they can make it happen themselves, exactly
   3. APPRECIATE  — they grasp the real-world IMPACT (→ severity → reward)
   4. FIX         — they know how to remediate it

Each maps to a known failure (5A.1’s rejection reasons): fail (1) and it is “insufficient information”; fail (2) and it is “not reproducible” — rejected; fail (3) and it is under-rated and under-paid; fail (4) and you have given them less than a complete, professional report.

A report that achieves all four is a report that gets paid its full value. Notice this is the same structure as a pentest finding (2.11) — title, severity, description, reproduction, evidence, impact, remediation — because a bug bounty report is a single, polished pentest finding. You already learned the shape; this page is about doing it excellently, because here it is the product.

Part 3: The Concept — The Anatomy of a Strong Report

A strong bug bounty report contains these components. (Platforms provide templates; the components are consistent.)

A clear, specific title. States the vulnerability type and where it is — e.g. the bug class and the affected component. A triager should know roughly what they are looking at from the title alone. Vague titles signal a vague report.

A concise summary. A short, plain-language statement of what the vulnerability is and why it matters — readable quickly by someone who has not yet dug in.

Severity / risk assessment. Your assessment of how serious it is — using the risk thinking (likelihood × impact, 1.1) and severity rating you learned in 2.11. Justified, not just asserted. (The company makes the final call, but a well-reasoned severity assessment frames it.)

Affected asset and scope confirmation. Exactly which in-scope asset is affected — confirming, implicitly, that you tested within scope (5A.1).

Reproduction steps. The single most important section. Precise, numbered, complete steps that let the team reproduce the vulnerability exactly. Every detail needed, nothing assumed. If they cannot follow your steps and see the bug themselves, the report fails — regardless of how real the bug is. Detailed in Part 4.

Proof of concept (PoC) and evidence. Supporting proof that the vulnerability is genuine — request/response captures, screenshots, a demonstration. Minimal and safe (the confirm-don’t-pillage discipline from Phase 2 — never include real user data you accessed; redact anything sensitive).

Impact. A clear explanation of what a real attacker could actually achieve — the realistic, concrete consequence. This is what drives severity and therefore reward. Detailed in Part 5.

Remediation guidance. Clear, actionable advice on how to fix it — drawing directly on your Phase 4 defensive knowledge. This is where being a purple practitioner pays off: you do not just report the attack, you help them defend. It marks you as professional and is genuinely valued.

Part 4: The Concept — Reproduction Steps, the Make-or-Break Section

Reproduction steps deserve their own focus, because more reports fail here than anywhere else.

The standard a triager applies: “Can I, following only this report, make the vulnerability happen myself?” If yes, your report can proceed. If no, it is rejected as not reproducible — even if the bug is completely real.

What makes reproduction steps excellent:

• Numbered and sequential. A clear ordered list — step 1, step 2, step 3 — that walks from start to demonstrated vulnerability.
• Complete — nothing assumed. Every action, every value, every prerequisite stated. The triager does not know what you know. A step you “obviously” skipped is a step they cannot follow.
• Precise. Exact URLs, exact inputs, exact requests. Not “modify the parameter” but precisely which parameter and to what.
• Self-contained. Everything needed to reproduce is in the report. The triager should not have to guess, infer, or contact you for missing detail.
• Tested. Before submitting, mentally (or actually) walk your own steps as if you knew nothing else. Find the gaps. Fix them.

   ❌ WEAK:  "There's an IDOR in the invoice feature, just
              change the ID and you get other users' invoices."
              → triager cannot reproduce precisely → rejected

   ✅ STRONG: numbered steps — log in as [test account], navigate
              to [exact location], capture [exact request],
              change [exact parameter] from X to Y, observe
              [exact result] — with evidence at the key step.
              → triager reproduces it exactly → proceeds

A report whose reproduction steps are excellent has cleared the highest bar between you and a reward.

Part 5: The Concept — Articulating Impact

If reproduction steps decide whether you get paid, impact largely decides how much.

Reward scales with severity, and severity is driven by demonstrated real-world impact (5A.1, and the risk thinking of 1.1). A vulnerability described only as a technical quirk gets a low rating. The same vulnerability, with its real-world consequence clearly articulated, gets rated — and paid — for what it actually is.

How to articulate impact well:

• Translate technical into consequence. Do not stop at “this endpoint has broken access control.” State what that means: what data could be accessed, what action an attacker could take, who is affected, how badly. The company’s severity decision is about consequence.
• Demonstrate, don’t just assert, where you can. Within scope and the confirm-don’t-pillage rule, show the impact — a safe proof-of-concept that demonstrates the consequence. Demonstrated impact is far more convincing than claimed impact. (Always: prove it minimally, never pillage real data — 5A.1, Phase 2.)
• This is where chaining pays off (5A.2). A chain demonstrates escalated impact — three low findings combined into a clearly-shown high-impact attack. The report of a chain shows the company the real, serious consequence, which is exactly what justifies a high-severity reward.
• Be accurate, not inflated. Articulate impact fully and convincingly — but honestly. Overstating impact (“this could destroy everything!” when it cannot) damages credibility and reputation. Triagers see exaggeration constantly; accurate, well-reasoned impact is what earns trust and, over time, access to better programs.

The skill: make the company see the real consequence of your finding — clearly, demonstrably, and honestly.

Part 6: The Concept — Professionalism and the Triage Relationship

A report is not only a technical document — it is a professional communication, and bug bounty is an ongoing professional relationship. Two final framings.

Professionalism in the report and after.

• Write clearly and professionally. Good structure, plain language, no sloppiness. The report represents you.
• Be honest and accurate. About impact, about what you did, about scope. Honesty builds the reputation that unlocks private programs (5A.1).
• Respond to triage professionally. After you submit, the triage team may ask questions, request clarification, or need more evidence. Respond promptly, helpfully, and politely. This back-and-forth is part of the job.
• Handle disagreement gracefully. Sometimes a report is rejected, marked duplicate, or rated lower than you hoped. You can professionally and politely make your case if you believe the assessment is wrong — but do so professionally, with evidence and reasoning, never with hostility. How you handle disagreement is part of your reputation.

Reputation is the long game. Every report contributes to your reputation on a platform (5A.1). A track record of clear, honest, professional, valid reports builds the reputation that unlocks private programs, better targets, and a sustainable practice (5A.5). Poor or dishonest reports do lasting damage. Each report is both an income event and a deposit into your professional standing.

🔑 The deep lesson: in bug bounty the report is the product. Finding the bug is half the work; communicating it — so the company can understand, reproduce, appreciate the impact, and fix it — is the half that actually gets paid. Excellent reproduction steps clear the rejection bar; well-articulated, honest impact drives the reward; professionalism builds the reputation that compounds into a real career. Treat every report as the deliverable it is.

📓 Key Terms

🧪 Hands-On Lab

Practice report-writing on findings from deliberately vulnerable apps, practice platforms, and CTFs — and on real findings from authorized programs. The skill is the writing; practice it on legal findings of any kind.

Task 1 — Study real reports. Read several responsibly-disclosed bug bounty reports (the disclosed reports from 5A.2). This time, study them as writing: how is the title phrased? how clear are the reproduction steps? how is impact articulated? Note what makes the strong ones strong.

Task 2 — Write a full report for a lab finding. Take a vulnerability you found in a deliberately vulnerable app (Phase 2 or 5A.2 labs). Write a complete bug bounty report with every component from Part 3 — title, summary, severity, affected asset, reproduction steps, PoC/evidence, impact, remediation.

Task 3 — Stress-test your reproduction steps. Take the report from Task 2. Walk through your own reproduction steps as if you knew nothing else about the finding. Find every gap, ambiguity, and assumed step. Rewrite until the steps are complete and self-contained.

Task 4 — Write up a chain. Take the chain you built in the 5A.2 lab. Write it as a report that demonstrates the escalated impact — showing how the combined findings produce a serious, concrete consequence. Practice articulating impact powerfully and honestly.

Task 5 — Practice impact articulation. Take three lab findings. For each, write two impact statements: a weak “technical quirk” version, and a strong “real-world consequence” version. See the difference clearly — this is what moves severity and reward.

Task 6 — Write the remediation sections. For each lab finding, write clear remediation guidance using your Phase 4 knowledge. Practice being the purple practitioner who reports the attack and the fix.

Task 7 — Build a report template. In Notion, create your own bug bounty report template with all the Part 3 components and notes-to-self on doing each well. You will reuse this for every real submission — and a good template makes every report faster and more consistent.

⚠️ Common Mistakes

• Treating the report as paperwork. The report is the product. Finding the bug is half the job; communicating it well is the half that gets paid.
• Weak reproduction steps. The number-one cause of rejected reports. Steps must be numbered, complete, precise, self-contained, and tested. The triager must be able to reproduce it from the report alone.
• Failing to articulate impact. A bug described as a technical quirk is under-rated and under-paid. Translate the technical finding into real-world consequence.
• Inflating impact. Overstating consequences damages credibility and reputation. Articulate impact fully but honestly.
• Including real user data as “evidence.” Confirm minimally, never pillage; redact anything sensitive. Pillaging is a crime (Phase 2 / 5A.1).
• Skipping remediation guidance. A report without it is incomplete and less professional. Use your Phase 4 knowledge — be the purple practitioner.
• Handling triage disagreement unprofessionally. Hostility damages your reputation. Make your case with evidence and reasoning, always professionally.

✅ Recap & What’s Next

• In bug bounty the report is the product — the company pays based on the report alone, which must make them understand, reproduce, appreciate the impact of, and fix the finding.
• Reproduction steps are make-or-break (numbered, complete, precise, self-contained, tested); impact articulation drives severity and reward (translate technical into real consequence — honestly); remediation guidance marks you as a purple professional.
• A report is also a professional communication — clarity, honesty, and graceful handling of triage build the reputation that compounds into a sustainable career.

Next (5A.5): You can now choose programs, recon at scale, hunt deeply, and report professionally. The final page turns these skills into a sustainable practice — managing the irregular income, the workflow, the burnout risk, and the long game of a real bug bounty career.