How Bug Bounty Actually Works

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

Core Philosophy: Bug bounty is the meeting point of three things you already have — offensive skill (Phases 2–3), the discipline of authorization (1.0), and professional communication (the reporting from 2.11). It is legal, paid, independent security work. But it is not a lottery and not a hobby that happens to pay — it is a profession with its own economics, rules, and craft. This page is the honest, complete picture of how it actually works.

Part 1: The Problem

You finished Phases 2–4 with real offensive skill and a stated goal: freelance in security. For most people, “freelance security work” begins with bug bounty — it is the most accessible entry, needs no employer, no client contracts to start, and no permission you have to negotiate yourself.

But bug bounty is widely misunderstood. People imagine either easy money or a hopeless lottery. The reality is a profession: it has economics, rules of engagement, a defined workflow, and a craft to master. Going in without understanding how it actually works leads to wasted effort, rejected reports, frustration — or, worst, stepping outside scope and committing an offense. This page gives you the accurate, complete picture before you invest serious time.

Part 2: The Concept — What a Bug Bounty Program Is

A bug bounty program is a standing, public (or invite-only) offer by an organization: “Find security vulnerabilities in our systems, within these rules, report them to us responsibly, and we will reward valid findings.”

It is the formalization of two things from earlier in the curriculum:

• Authorization at scale (1.0). The program is the written authorization — a company publicly inviting testing. This is what makes bug bounty legal hacking: the company has consented, in advance, in writing, within defined limits.
• Responsible disclosure with a reward (1.0). You report privately, give them a chance to fix, and — because the finding has value to them — you are paid.

Why companies run them: more eyes find more bugs; paying for vulnerabilities found by friendly researchers is far cheaper than suffering a breach; and it channels security research into a controlled, legal path instead of an uncontrolled one.

   COMPANY                          YOU (the researcher)
   publishes a program  ────────►   read the program & scope
   defines scope & rules            test ONLY in-scope, by the rules
   sets reward ranges               find a real vulnerability
   receives your report  ◄────────  write & submit a clear report
   triages & validates it
   pays for valid findings ────────► reward + reputation

Part 3: The Concept — Platforms, Programs, and the Two Models

Bug bounty platforms. Most bug bounty happens through platforms — intermediary services that host many companies’ programs, standardize the process, handle reporting and payment, and run reputation systems for researchers. You create one account and can access many programs. There are several major platforms; you do not need to pick a “best” one — many researchers use more than one.

Programs come in two broad models:

• Bug bounty programs — you are paid for valid findings, with reward amounts varying by severity.
• Vulnerability Disclosure Programs (VDPs) — a company invites and accepts security reports but does not pay (you may get recognition/thanks). VDPs are still valuable to a newcomer: they are real, legal, authorized targets to practice on and to build a track record.

Programs are also public or private:

• Public programs — open to any researcher. Where most people start. Often more crowded (more competition for the same bugs).
• Private programs — invite-only, typically extended to researchers who have built a reputation. Less crowded, often better targets. A reason to build reputation early (Part 6, and 5A.5).

The practical takeaway: you start on a platform, on public programs and VDPs, and as your reputation grows you gain access to private programs.

Part 4: The Concept — Scope and Rules of Engagement (the part you must not get wrong)

Every program has a scope and rules — and this is the single most important section of this page, because getting it wrong turns legal work into a crime.

Recall scope from page 1.0: the explicit definition of what you may test and how. A program page spells this out, and you read it completely, every time, before testing anything.

A program’s scope and rules typically define:

• In-scope assets — the exact domains, applications, IP ranges, mobile apps you may test.
• Out-of-scope assets — explicitly forbidden, even though they belong to the same company. Testing these is unauthorized access (1.0), full stop.
• In-scope vulnerability types — what they want reported.
• Out-of-scope / ineligible findings — issue types they will not accept or pay for (every program has a list — see Part 5).
• Forbidden techniques — almost always: no denial-of-service / no degrading the service; usually no social engineering of staff; no testing that affects real users; no automated scanning that hammers their systems.
• Rules on data — what to do if you encounter real user data: stop, do not access further, report. Never exfiltrate or hoard real data — proving a bug exists is the job; pillaging is a crime (the confirm-don’t-pillage discipline from all of Phase 2).
• Disclosure rules — whether/when you may write publicly about a finding (usually only with the company’s coordination).

        THE PROGRAM PAGE — read ALL of it, every time
   ┌──────────────────────────────────────────────────┐
   │ ✅ IN SCOPE      — test ONLY here                  │
   │ ❌ OUT OF SCOPE  — off-limits, even same company   │
   │ 📋 RULES         — forbidden techniques, data rules│
   │ 🚫 INELIGIBLE    — issue types they won't accept   │
   │ 💰 REWARDS       — ranges by severity              │
   └──────────────────────────────────────────────────┘
   Scope is a CONTRACT. Outside it = unauthorized access.

🔑 The unbreakable rule of this entire track: the program scope is the boundary of your authorization. In scope, by the rules = legal, professional work. One step outside = a criminal offense, regardless of intent or whether you “found something interesting.” When you find something juicy that is out of scope: do not touch it. Note that it exists, and report it through the proper channel if the program allows. Discipline here is not optional — it is the profession.

Part 5: The Concept — How Findings Are Judged and Rewarded

When you submit a report, the company (or the platform’s triage team) evaluates it. Understanding this process saves you enormous wasted effort.

Validity. Is it a real, reproducible vulnerability? This is why reproduction steps matter so much (2.11, and 5A.4) — an unreproducible report gets rejected.

Severity. How serious is it? Judged on impact and exploitability — the risk = likelihood × impact thinking from 1.1, and the severity rating you learned to assign in 2.11. Reward scales with severity: low-severity findings earn modest rewards; critical findings can earn substantial ones.

In scope and eligible. It must be an in-scope asset and an accepted issue type.

Uniqueness — first to report. This is a defining economic reality of bug bounty: rewards generally go to the first person to report a given bug. Two consequences: (1) duplicates — submitting a real bug someone already reported earns nothing; (2) on crowded public programs, the “easy” bugs are often already found. This is why depth, good recon, and less-crowded programs matter (5A.2, 5A.3, 5A.5).

Common reasons reports are rejected — know these so you do not waste effort:

• Duplicate — already reported.
• Out of scope — wrong asset, or ineligible issue type.
• Not a real vulnerability — a theoretical concern with no demonstrated impact, or expected behavior.
• Known/accepted issue — the company already knows and has accepted the risk.
• Insufficient information — not reproducible from the report.
• Low/no impact — technically a quirk but no security consequence.

The honest framing: bug bounty rewards valid, in-scope, unique, well-reported, real-impact findings. Each of those words is a filter. The craft of the rest of this track is getting through all of them.

Part 6: The Concept — The Bug Bounty Workflow, and an Honest Reality Check

The workflow — and notice it is exactly the methodology you already built, now aimed at a bounty target:

   1. CHOOSE a program — read scope & rules COMPLETELY (5A.1, 5A.5)
   2. RECON — map the in-scope attack surface (Phase 2.1, 5A.3)
   3. TEST — hunt for vulnerabilities (Phases 2–3, 5A.2)
   4. VERIFY — confirm it's real, with a minimal safe PoC (2.11)
   5. REPORT — write a clear, professional report (5A.4)
   6. FOLLOW UP — respond to triage questions professionally
   7. GET PAID — reward + reputation; repeat

Bug bounty is the 2.11 pentest methodology, run continuously, against authorized programs, for pay.

An honest reality check — because false expectations end bug bounty careers before they start:

• Income is uneven and not guaranteed. Bug bounty does not pay a salary. Some weeks: nothing. Some months: a great find. Income is irregular by nature — plan for that (5A.5 covers this directly).
• It is competitive. Many researchers hunt the same public programs. The easy bugs go fast.
• It rewards persistence and depth. Beginners who treat it as a lottery quit. Those who treat it as a craft to steadily improve — better recon, deeper techniques, less-crowded programs, sharper reports — succeed over time.
• It is a real skill that compounds. Every program teaches you something; reputation opens private programs; skill deepens. It gets better with time and deliberate effort.
• It pairs well with other things. Many people do bug bounty alongside employment, or alongside other freelance security work (5A.5, 7.4) — exactly because the income is irregular.

Bug bounty is a genuine, accessible, legal path into security freelancing — if you go in understanding it as a profession with a craft, not a slot machine.

📓 Key Terms

🧪 Hands-On Lab

All tasks here involve reading and understanding real programs and practicing on authorized targets. You do not test any live program until you have completed the rest of Track A and are deliberate about scope.

Task 1 — Create platform accounts. Sign up on one or two major bug bounty platforms. Explore the interface — how programs are listed, how reports are submitted.

Task 2 — Read five real program pages. Pick five public programs and read each program page completely. For each, identify in-scope assets, out-of-scope assets, forbidden techniques, ineligible issue types, reward ranges, and data-handling rules. Notice how specific and how different they are.

Task 3 — Find the VDPs. Identify several Vulnerability Disclosure Programs (no payment). Note them — these are good, low-pressure, authorized targets to build a track record on once you start.

Task 4 — Study the rejection reasons. For one platform, read its guidance on what makes reports valid vs rejected. Write the rejection reasons from Part 5 in your own words — you are learning what not to waste effort on.

Task 5 — Map the workflow to what you know. In Notion, write the bug bounty workflow from Part 6 and, beside each step, the curriculum page(s) that taught it. See that bug bounty is your existing skills, re-aimed.

Task 6 — Honest expectations note. In Notion, write your own honest summary of the Part 6 reality check — income irregularity, competition, the persistence required. Revisit it whenever bug bounty feels discouraging; realistic expectations are what keep people going.

Task 7 — Pick a starter program. Choose one beginner-friendly program (or VDP) with a clear, generous scope that you will work through later in the track. Read its scope twice. Do not test yet — first finish 5A.2–5A.5.

⚠️ Common Mistakes

• Not reading the full scope, every time. The single most dangerous mistake. Out-of-scope testing is unauthorized access — a crime — even on the same company. Read the whole program page before testing anything.
• Treating bug bounty as a lottery. It is a craft with economics and a workflow. People who expect easy money quit; people who steadily improve succeed.
• Expecting steady income. Income is irregular by nature. Plan for that (5A.5) — many pair it with employment or other work.
• Chasing only crowded public programs. The easy bugs are gone first. Depth, recon, and less-crowded programs matter (5A.2, 5A.3, 5A.5).
• Submitting low-impact or theoretical “findings.” Reports need demonstrated, real impact. Quirks with no security consequence get rejected.
• Touching out-of-scope assets because they “looked interesting.” Note it; do not test it. Discipline on scope is the profession.
• Hoarding or exfiltrating real data to “prove” a bug. Confirm minimally; never pillage. That crosses into a crime (the Phase 2 discipline).

✅ Recap & What’s Next

• Bug bounty is legal, paid, independent security work — a company’s standing, written authorization (1.0) to find and responsibly report vulnerabilities for a reward.
• It runs through platforms, on public/private programs and unpaid VDPs; the scope is the boundary of your authorization — outside it is a crime; findings must be valid, in-scope, unique, well-reported, and real-impact to be rewarded.
• It is a profession with a craft, not a lottery — income is irregular, it is competitive, and it rewards persistence and depth; the workflow is the 2.11 methodology aimed at bounty targets.

Next (5A.2): On crowded programs the obvious bugs are gone. To find what others miss, you need to hunt deeper — beyond the OWASP Top 10, into bug classes and chaining that less-skilled hunters never reach.