🧪 Labs › Programmes & Reporting
🏁 Part of the Web & Bug Bounty path — module 8, Capstone — a Real Programme
Scope, Triage & Writing the Report
Severity: Informational
On a real programme, the report is the product. The bug is just the evidence.
What it is
A bounty programme pays for reports, not for bugs. Two hunters can find the same issue and receive very different outcomes — one gets paid, one gets closed — because of scope, duplicates, evidence and how impact was framed.
Scope is binding. A policy lists what you may test, what you may not, and the rules of engagement (rate limits, test accounts, no data destruction). Testing out of scope is not a grey area: on a real programme it can get you banned and removes safe-harbour protection. Hosts that are out of scope often still answer — that is exactly why the policy exists.
Not every real bug is a payable bug. Programmes publish known issues and exclusions; a valid finding that is already disclosed is a duplicate, and a valid finding with no meaningful impact is informational. Recognising those before you submit protects your signal — the reputation score that decides which private programmes invite you.
Severity is argued, not asserted. Triagers score on what an attacker gains, under what conditions, against which asset. A report that states that in the programme's own terms gets triaged faster and scored higher than one that names the vulnerability class and stops.
How to approach it
- Read the whole policy before sending a single request: in scope, out of scope, rules, known issues, severity guidance and what a report must contain.
- Write the scope list down where you will see it while you work, and check every new host against it.
- Budget your time: map the in-scope surface, prioritise the areas where impact would be highest, and leave the rest documented as not tested.
- For each candidate finding, check the known-issues list and exclusions before writing it up.
- Write each report as: the asset, the exact request, what an attacker gains, your claimed severity with the reason, and the fix.
How you'll recognise it
The tells that should make you slow down and test this class properly.
- A policy, security.txt or scope page — find it first.
- Several hosts on one address, distinguished only by name, some of them out of scope.
- A 'known issues' or 'exclusions' section that describes something you can reproduce.
- Rate limits and test-account rules that apply to your tooling as well as to you.
Your task
Work a written disclosure programme inside its scope, find the issues worth reporting, recognise the one that is not, and submit a report and a short debrief.
▶ Access the labOpens your hosted RatCTF instance. Work on it directly — there's nothing to submit here; you'll know when you've solved it.
Proving it to a triager
On a real programme the report is what gets paid. What the evidence needs to show, and what usually gets it closed.
- Lead with the most severe in-scope issue and the exact request that proves it.
- Frame impact in the programme's language: whose data, how much, what an attacker does with it.
- Connect related findings when one explains another — a disclosed configuration that names the missing control strengthens the main report.
- Leave out, or explicitly mark as duplicate, anything the policy already discloses.
🎓 Want the full course? — from Uncle Rat, half price with code DISCOUNT
How to prevent it
- For programme owners: publish a clear, current scope and keep the known-issues list up to date — it saves both sides time.
- Give hunters test tenants and accounts so they never need to touch real customer data.
- Respond to reports with a reason, especially when closing them; it raises the quality of what you receive next.