Bug › Module 8 › Lesson 1
Good vs Bad
Bug bounty report quality — what triagers accept vs reject on $PROGRAM submissions.
Visual · t20_good_vs_bad
Good report = clear, in-scope, minimal proof, fix hint. Original Cyberlium.
Opening
Triagers close bad reports in minutes — learn the shape of a report that gets paid and fixed.
Good bounty reports: descriptive title with asset and class, clear scope reference ($PROGRAM asset URL), numbered reproduction steps, minimal redacted proof, impact paragraph tied to program severity rubric, remediation hint, no attitude. Bad reports: 'site is hackable,' no steps, out-of-scope host, scanner dump, demands for CVSS without context, live creds in screenshot, duplicate without checking, threats about disclosure deadlines on day one. Cyberlium contrasts examples using YOUR $LAB_BOUNTY or sanitized fictional samples — not copying live HackerOne reports with real company names as templates for stranger submissions. Write for the engineer who will patch at 2 a.m. — clarity is kindness and payment velocity.
1. Good report signals
Specific title, in-scope URL, prerequisites, repro steps, proof, impact, suggested fix, polite tone.
Links asset map row ID from Module 5 — shows intentional hunting, not random spray.
Command guide
Try these commands — Good report signals
═══ TOOLS & WEBSITES ═══ Browse / read these (authorized learning only — stay in YOUR lab / program scope)
Report draft — AFTER real recon from modules 4–5 Platform template — HackerOne / Bugcrowd format
═══ INSTALL ═══
Linux (Debian/Ubuntu):
Command — copy this
sudo apt install curl
macOS: Built-in
Windows: Built-in (PowerShell: Invoke-WebRequest)
═══ LINUX / macOS ═══
Command — copy this
grep -h . "$HOME/cyberlium-lab/t20-asset-map.txt" 2>/dev/null | head -10 source "$HOME/cyberlium-lab/t20-scope.env"; curl -sS "https://$SCOPE_HOST/robots.txt" 2>/dev/null | head -8 || curl -sS https://httpbin.org/robots.txt | head -8
Primary tools to practice this lesson: grep, curl. Reference sites: Report draft; Platform template. Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. Bad report signals
Vague title, OOS asset, no repro, scanner attachment only, entitlement tone, public disclosure threats immediately.
Live PII, full session tokens, unrelated CVE paste without proving affected endpoint on scope.
3. Defender handoff
Good reports map to ticket fields: component, severity, repro, fix — speeds patch and retest.
Bad reports consume triage SLA and reduce hunter reputation score on platform.
4. What you ship: good vs bad contrast
Side-by-side outline: one good report skeleton vs five bad patterns to avoid.
5. What you record before the next lesson
Good vs bad contrast path.
6. Wrong vs right: random sites vs in-scope program
Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.
Wrong
Submit 'Critical XSS' with no URL and a meme screenshot.
Right
Good vs bad contrast written. Next: Steps and Impact.
Mission: good vs bad contrast
1) Write good report section headers. 2) List five bad patterns. 3) Add polite tone rule. 4) Tie to $PROGRAM scope reference.
Stuck? Ask Cyberlium AI Mentor
Ask Mentor: “Title format — asset first or class first?”
Knowledge Check
APPLY: Good report includes:
Multiple choice
Knowledge Check
APPLY: True or False: Live creds in screenshots help triage.
True or False
Knowledge Check
APPLY: Bad report often has:
Multiple choice