dragonked2 / report

REPORT WRITING — GATE-VALIDATED REPORTS

Every report must reference the 7-gate validation that the finding passed.

PRE-SUBMISSION CHECKLIST

Before writing ANY report, verify the finding state:

FINDING STATE: VALIDATED (passed all 7 gates)
  Gate 1 (Scope): ✓ Asset in program scope
  Gate 2 (Boundary): ✓ Security boundary violation identified
  Gate 3 (Attacker): ✓ Realistic attacker capability
  Gate 4 (Reproducible): ✓ Deterministic reproduction
  Gate 5 (Impact): ✓ Concrete security impact
  Gate 6 (FP): ✓ False positive eliminated
  Gate 7 (Program): ✓ Program accepts this finding

IF ANY GATE FAILED → DO NOT WRITE REPORT

REPORT TEMPLATES

HackerOne Report

# Summary

Vulnerability type: [Vulnerability Type]
Vulnerability severity: [Critical/High/Medium/Low/Info]
Weakness: [CWE-XXX]

# Vulnerability Detail

[Detailed technical explanation]

# Steps To Reproduce

1. [Exact HTTP request — copy-paste ready]
2. [Exact response showing impact]
3. [Screenshot/video of impact]

# Proof of Concept

[Request/Response pairs, screenshots, code]

# Impact

[Business impact, affected users, data exposure]

# Remediation

[Specific fix recommendations]

# Supported Scenario

[When this vulnerability can be exploited]

# Out Of Scope

[Any limitations or edge cases]

Bugcrowd Report (VRT-aligned)

# Vulnerability Name

**VRT Category**: [Category from VRT]
**VRT Subcategory**: [Subcategory]
**Severity**: [P1-P5]

## Description
[Technical description]

## Impact
[Business impact]

## Steps to Reproduce
1. [Step 1]
2. [Step 2]
3. [Step 3]

## Proof of Concept
[Evidence]

## Remediation
[Fix recommendation]

Immunefi Report (Web3)

# Summary

Vulnerability Type: [Type]
Affected Protocol: [Name]
Chain(s): [Ethereum, BSC, etc.]
Severity: [Critical/High/Medium/Low/Info]

## Vulnerability Description
[Technical details]

## Impact
[Financial impact, affected users]

## Proof of Concept
[Steps and evidence]

## Remediation
[Fix recommendations]

SEVERITY MAPPING

CVSS Scoring

Severity Justification

Pick severity from the impact you demonstrated, and show the reasoning so
the owner (or triager) can disagree with evidence rather than opinion:

Two rules that keep reports honest:

• Do not inflate. If you proved a read-only IDOR, it is not Critical just
  because write access might exist. State the demonstrated severity.

• Do not under-report by timidity. A proven high-impact bug reported as
  "medium, probably" is as wrong as inflation — say what you showed.

• Chains are notes, not severity. "This may compound with an XSS on the
  same origin" belongs in an analyst note, not in the impact score.

SEVERITY FILTERING

When the user scopes the report ("Critical only", "High and above"):

1. Parse the filter at assessment start and record it in the scope
   file (see scope skill) — e.g. Severity focus: Critical only.

2. Tag EVERY finding with a severity DURING testing, not at report time.

3. At report time, include only matching findings. State explicitly
   what was tested but filtered out:
   Tested: XSS, open redirect, headers (below Critical threshold — excluded).

4. Critical means: RCE, SQLi with data exfiltration, SSRF with
   internal-network access, auth bypass / ATO. Never inflate a
   Medium to fill a Critical-only report — report "no Critical
   findings" with the no-finding checklist (see runbook 10.9) instead.

EVIDENCE STANDARD

Every finding ships with request + response + status code + impact
analysis (full templates live in the evidence-locker skill):

• Auth findings: demonstrated with real authenticated requests —
  an unauthenticated CORS/CSRF observation without authed impact
  is not a finding.

• RCE: full command-execution output.
• Data exposure: the exposed data and why it is sensitive.

• Link each finding to its evidence IDs (EVD-001…); no evidence,
  no report.

WRITING BEST PRACTICES

Title

• Be specific: "IDOR in /api/users/{id} allows reading any user's PII"
• Not generic: "Security Vulnerability Found"

Summary

• One paragraph maximum
• What, where, impact
• No technical jargon

Steps to Reproduce

• Numbered list
• Exact URLs and parameters
• Include request/response pairs
• Reproducible by anyone

Impact

• Business impact, not just technical
• Quantify if possible (users affected, data exposed)
• Real-world scenario

Remediation

• Specific, actionable recommendations
• Not just "fix the vulnerability"
• Include code examples if helpful

COMMON MISTAKES TO AVOID

1. Vague titles — "Security Issue" vs "IDOR in /api/users/{id}"
2. Missing impact — Technical details without business context
3. Unreproducible steps — Steps that don't work for triagers
4. Sensitive data — Including real PII in reports
5. Poor formatting — Walls of text without structure
6. Duplicate submissions — Not checking Hacktivity first
7. Out of scope — Testing excluded assets
8. Theoretical impact — "Could potentially" instead of "did"

EVIDENCE CLEANING

# Remove PII from screenshots
# Blur names, emails, phone numbers
# Use placeholder data

# Clean request/response pairs
# Remove session tokens
# Remove real credentials
# Use [REDACTED] for sensitive values

# Sanitize logs
# Remove IP addresses
# Remove usernames
# Use generic placeholders

SUBMISSION PLATFORMS

HackerOne

• https://hackerone.com
• Follow program rules strictly
• Use their report template
• Check Hacktivity for duplicates

Bugcrowd

• https://bugcrowd.com
• Align with VRT (Vulnerability Rating Taxonomy)
• Use their severity definitions
• Follow disclosure policy

Intigriti

• https://intigriti.com
• European bug bounty platform
• Follow their submission guidelines
• Check for duplicate reports

Immunefi

• https://immunefi.com
• Web3/DeFi focused
• Follow their disclosure policy
• Report demonstrated impact; do not inflate a theoretical drain into a Critical

REPORT REVIEW CHECKLIST

Before submitting:

• [ ] Title is specific and descriptive
• [ ] Summary is clear and concise
• [ ] Steps are reproducible
• [ ] Evidence is clean (no PII)
• [ ] Impact is quantified
• [ ] Remediation is actionable
• [ ] Formatting is consistent
• [ ] No sensitive data exposed
• [ ] Duplicate check completed
• [ ] Program rules followed
• [ ] All 7 gates passed (documented in finding state)
• [ ] Severity matches demonstrated impact