Module 11: Bug Bounty Programs¶

← Module 10: CTF Methodology | Topic Home | Next: Capstone Project →

Bug bounty hunting is where security research becomes professional — the difference between a finding and a payout is a well-written report that the triage team can act on.

[!NOTE] Stub Module — Full theory content will be expanded in a future update.

Table of Contents¶

1. Overview
2. Prerequisites
3. Objectives
4. Theory
5. Key Concepts
6. Examples
7. Common Pitfalls
8. Cross-Links
9. Summary

Overview¶

Bug bounty programs formalize the relationship between security researchers and organizations. Companies publish programs defining what systems can be tested, what vulnerability types they care about, and what they will pay for valid findings. Researchers find vulnerabilities, submit reports, and receive payment for valid, in-scope bugs.

The economics of bug bounty are real: top researchers on HackerOne earn over $1 million per year. But the barrier to entry is high — not because the technical skills are rare, but because the skills for writing a clear, actionable, impactful report are underdeveloped in most beginners. This module teaches the complete workflow: program selection, systematic testing, report writing (CVSS scoring, reproduction steps, impact statement, remediation recommendations), and the responsible disclosure timeline.

Prerequisites¶

• All previous modules (01–10) — bug bounty requires the full skill set
• [[pentesting-security/modules/03_web-application-security]] — OWASP vulnerabilities are the most common findings
• [[pentesting-security/modules/07_recon-and-osint]] — Recon-first approach to finding the attack surface

Objectives¶

By the end of this module, you will be able to:

1. Choose appropriate bug bounty programs based on scope, payout, and your skill level
2. Perform systematic recon and testing against a bug bounty target within scope
3. Calculate CVSS scores for discovered vulnerabilities using the CVSS calculator
4. Write a complete, professional vulnerability report with all required sections
5. Describe the responsible disclosure timeline and the researcher's obligations
6. Differentiate between a valid finding and an "out-of-scope" or informational report
7. Handle triage communication professionally — follow-up, questions, appeals

Theory¶

The Bug Bounty Economy¶

Bug bounty programs exist because the cost of paying researchers is far lower than the cost of a breach. Major programs and their characteristics:

Payout tiers by severity (approximate): - Critical (CVSS 9.0+): \(5,000–\)100,000+ - High (CVSS 7.0–8.9): \(1,000–\)20,000 - Medium (CVSS 4.0–6.9): \(300–\)3,000 - Low (CVSS 0.1–3.9): \(50–\)500 - Informational: $0 (but sometimes swag/acknowledgment)

Choosing a Program¶

PROGRAM SELECTION CRITERIA:

1. SCOPE WIDTH — A wide scope (e.g., "*.company.com") gives more targets.
   Narrow scope (e.g., only "api.company.com/v2") has fewer competitors but fewer targets.

2. AVERAGE PAYOUT — Check the program's statistics page on the platform.
   Programs with $500 average payout require the same work as $5,000 average programs.

3. RESPONSE TIME — Programs with 60+ day median response time are frustrating.
   Look for programs with <14 day median time to triage.

4. DUPLICATE RATE — High duplicate rates mean the easy bugs are found.
   Look for newer programs or programs with expanding scope.

5. YOUR SKILL MATCH — Choose programs where your strongest vulnerability classes
   (web app, API, mobile) match the target type.

BEGINNER RECOMMENDATION:
- Start with programs marked "VDP" (Vulnerability Disclosure Program) — no payment, but
  also lower competition and no expectation of breadth
- Practice on public programs with wide scope and decent response times
- Build your first 5–10 reports on medium-severity findings before chasing criticals

CVSS Scoring¶

The Common Vulnerability Scoring System v3.1 provides a standardized way to rate vulnerability severity. The base score is computed from 8 metrics:

CVSS:3.1 Base Metrics:

Attack Vector (AV): Network(N) / Adjacent(A) / Local(L) / Physical(P)
  N = any internet user can exploit → highest severity

Attack Complexity (AC): Low(L) / High(H)
  L = no special conditions required → higher severity

Privileges Required (PR): None(N) / Low(L) / High(H)
  N = no authentication needed → highest severity

User Interaction (UI): None(N) / Required(R)
  N = victim doesn't need to do anything → higher severity

Scope (S): Unchanged(U) / Changed(C)
  C = impact extends beyond vulnerable component → higher severity

Confidentiality (C): None(N) / Low(L) / High(H)
  H = complete data disclosure possible → highest severity

Integrity (I): None(N) / Low(L) / High(H)
Availability (A): None(N) / Low(L) / High(H)

EXAMPLE: Unauthenticated SQLi with full data dump
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
→ Score: 9.1 (Critical)

Use the CVSS calculator: https://www.first.org/cvss/calculator/3.1

Writing a Professional Bug Bounty Report¶

## Title
[Clear, specific vulnerability title]
Example: "SQL Injection in /api/search Endpoint Allows Unauthenticated Data Extraction"

## Severity
Critical / High / Medium / Low
CVSS Score: [X.X] — CVSS:3.1/[vector string]

## Summary
[2-3 sentences: what the vulnerability is, where it is, and the impact]

## Affected Endpoint(s)
- Method: POST
- URL: https://api.example.com/v2/search
- Parameter: `query` (POST body)
- Authentication: None required

## Vulnerability Description
[3-5 paragraphs explaining:]
- What the vulnerability is technically
- Why it exists (root cause)
- How it was discovered
- What an attacker could do with it

## Reproduction Steps
[Exact, step-by-step instructions. Copy-paste friendly. Include:]
1. Send the following HTTP request using curl or Burp Suite:
   ```
   POST /api/v2/search HTTP/1.1
   Host: api.example.com
   Content-Type: application/json

   {"query": "test' UNION SELECT username, password FROM users--"}
   ```
2. Observe the response:
   ```json
   {"results": [{"username": "admin", "password": "..."}]}
   ```

## Impact
[Explain business consequences:]
- What data can an attacker access?
- What operations can they perform?
- Who is affected? (all users, specific user types)
- Regulatory implications? (PCI, HIPAA, GDPR)

## Proof of Concept
[Screenshot or terminal output showing the vulnerability working]
[Note: minimize actual data extraction — prove it works without dumping everything]

## Suggested Remediation
[Specific, technical fix:]
- Use parameterized queries for all database operations
- Example: `cursor.execute("SELECT ... WHERE query = ?", (query,))`
- Additionally: implement input validation, WAF rules as defense-in-depth

## References
- CVE: [if applicable]
- OWASP: https://owasp.org/www-community/attacks/SQL_Injection
- CWE-89: Improper Neutralization of Special Elements in SQL Commands

Responsible Disclosure Timeline¶

COORDINATED DISCLOSURE TIMELINE:

Day 0:   Researcher discovers vulnerability
Day 1:   Researcher reports to vendor/platform (submit bug report)
         Researcher confirms receipt of report

Days 1-7:  Vendor acknowledges report and begins triage

Day 30: If no response or triage, researcher sends follow-up
        "I submitted report [ID] on [date]. Awaiting triage confirmation."

Day 60: If still no response, researcher notifies intent to publish

Day 90: Public disclosure deadline — researcher may publish regardless of
        whether vendor has patched
        Note: Google Project Zero uses 90-day policy; HackerOne programs vary

GRACE PERIODS:
- Actively exploited vulnerabilities: consider shorter timeline or immediate disclosure
- Complex vulnerabilities requiring major architectural changes: may negotiate extension
- Critical infrastructure / healthcare: may warrant extended coordination

AFTER PATCH RELEASE:
- Always wait for the vendor to confirm a patch is released before full disclosure
- Give users time to update (typically 7-30 days after patch before publishing PoC)

Key Concepts¶

VDP (Vulnerability Disclosure Program) — A program that accepts vulnerability reports but does not offer monetary rewards. Good for building skills and a track record before targeting paid programs. The DoD's Vulnerability Disclosure Policy is the world's largest VDP.

In Scope / Out of Scope — The program's policy page defines exactly what is and is not authorized for testing. Testing out-of-scope assets can result in program ban and potential legal action. Always check scope before starting testing.

Duplicate Report — A report for a vulnerability that has already been submitted by another researcher. Duplicates receive no payout. The earlier submission wins. This is why good recon (finding unique attack surface) and speed matter.

Triage — The process by which the program team reviews submitted reports to determine: validity (is it actually a bug?), scope (is the affected asset in scope?), severity (CVSS), and whether it is a duplicate.

Examples¶

Example 1: CVSS Score Calculation¶

# This is not a real CVSS library — it demonstrates the conceptual calculation
# Use https://www.first.org/cvss/calculator/3.1 for real calculations

def describe_finding(vulnerability_name: str, cvss_vector: str, score: float) -> None:
    """Format a finding with CVSS context for a bug bounty report."""
    severity = (
        "Critical" if score >= 9.0 else
        "High" if score >= 7.0 else
        "Medium" if score >= 4.0 else
        "Low" if score > 0 else
        "None"
    )

    print(f"Vulnerability: {vulnerability_name}")
    print(f"CVSS Vector:   {cvss_vector}")
    print(f"CVSS Score:    {score} ({severity})")
    print()

# Common vulnerability CVSS examples
findings = [
    (
        "Unauthenticated SQL Injection in Search API",
        "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
        9.1
    ),
    (
        "Stored XSS in User Profile Bio",
        "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
        5.4
    ),
    (
        "IDOR on Invoice Download — Read Other Users' Invoices",
        "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
        6.5
    ),
    (
        "Reflected XSS with Trivial Filter Bypass",
        "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
        6.1
    ),
]

for name, vector, score in findings:
    describe_finding(name, vector, score)

Common Pitfalls¶

Pitfall 1: Submitting before fully understanding the impact. A report that says "I found SQLi and you should fix it" without demonstrating impact will be triaged as low severity even if it is critical. Prove the impact: what data can be accessed, what operations can be performed.

Pitfall 2: Testing out of scope and submitting anyway. Many beginners find bugs on systems they were not authorized to test and submit them anyway. Programs ban researchers who do this. Always check scope first; if it's out of scope, look for a general responsible disclosure channel.

Pitfall 3: Underestimating report quality. The difference between a $200 report and a $5,000 report for the same vulnerability is often entirely in the quality of the report — clear steps, precise impact analysis, and actionable remediation. Invest time in the report.

Cross-Links¶

• [[pentesting-security/modules/03_web-application-security]] through [[pentesting-security/modules/09_post-exploitation]] — All technical vulnerability modules feed into bug bounty
• [[pentesting-security/modules/12_capstone-project]] — The capstone requires a professional penetration test report using these skills

Summary¶

• Bug bounty programs formalize authorized security research with monetary rewards
• Program selection matters: scope, payout, response time, duplicate rate, skill match
• CVSS v3.1 provides an 8-metric framework for quantifying vulnerability severity
• A professional report has: clear title, CVSS score, exact reproduction steps, impact analysis, remediation
• Responsible disclosure: report → 90-day coordination window → publish with or without patch
• Quality of the report often determines payout — more than the technical complexity of the finding
• Start with VDPs (no payout, lower competition) before targeting high-payout programs