In 2016, the U.S. Department of Defense launched "Hack the Pentagon" through HackerOne, the first federal bug bounty program, and submissions poured in almost immediately — the first report arrived within 13 minutes, and by the six-hour mark nearly 200 had been filed. A decade later, HackerOne alone has paid hackers well over $300 million in bounties across its platform history, and Google's Vulnerability Reward Program has paid out more than $80 million cumulatively since it started in 2010. Those numbers make bug bounty hunting look like a straightforward path from spare time to spare income, and for a small number of top researchers it is — but the median outcome for someone submitting their first report is a "duplicate" or "not applicable" closure, not a check. Bounty payouts also vary enormously: a low-severity or informational finding on most programs pays somewhere in the $50–$500 range, while a critical remote code execution finding on a major program can pay $10,000 to $100,000 or more, with exact numbers set per-program and usually keyed to a CVSS-based severity rubric. This piece walks through how bounty programs are actually structured, which platforms dominate the space, and — the part most beginner guides skip — how to write a report that survives triage instead of getting closed as a duplicate.
How does a bug bounty program actually work?
A bug bounty program is a standing offer: a company defines which of its assets researchers may test, publishes rules for how findings must be reported, and pays out based on a severity rubric — usually mapped to CVSS — once a report is validated. The scope document is the contract. It lists in-scope domains, apps, and API endpoints, explicitly excludes assets like third-party vendor infrastructure or old subdomains, and states what techniques are off-limits (denial-of-service testing and social engineering are almost universally banned). Alongside scope sits a "safe harbor" clause, which is the company's written commitment not to pursue legal action against researchers who test within the stated rules — this is what makes the arrangement meaningfully different from unauthorized hacking. Programs can be public (anyone can participate) or private/invite-only, where a platform selects a smaller pool of vetted researchers, often to reduce noise on sensitive targets. Every serious platform tells new researchers the same thing first: read the scope and the terms before you send a single request, because testing an out-of-scope asset is one of the most common reasons accounts get suspended.
Which platforms should a new researcher actually use?
HackerOne and Bugcrowd are the two dominant public bug bounty platforms, and together they host thousands of programs spanning software companies, financial institutions, and government agencies. Beyond those two, Intigriti has built a strong European program base, YesWeHack focuses similarly on the EU market, and Synack runs an invite-only, vetted researcher model that pairs human testers with its own scanning infrastructure rather than accepting open public submissions. For a new researcher, HackerOne and Bugcrowd are the practical starting point specifically because they publish extensive public disclosure archives — past reports that companies have agreed to make visible — which function as a free training library showing exactly what a validated, well-written report looks like for a given vulnerability class. Some vendors also run bounty programs directly rather than through a third-party platform: Google's VRP and Microsoft's MSRC bounty program both publish their own scope and payout tables, and both predate the rise of the platform model, with Google's VRP running continuously since 2010.
What actually determines payout size?
Payout size is set by the program owner, not the platform, and is typically driven by a severity rubric — most commonly built on CVSS — combined with the business criticality of the affected asset. The same vulnerability class can pay wildly different amounts on different programs: a reflected XSS finding might be informational-only on one program's login page and pay four figures on another program if it hits an authenticated admin panel. As a rough shape of the market, low-severity or informational findings (missing security headers, verbose error messages, minor information disclosure) commonly land in the $50–$500 range, medium-severity findings with clearer exploitation paths often fall in the low thousands, and critical findings — remote code execution, full account takeover, or severe authentication bypass — can reach $10,000 to $100,000+ on well-funded programs. There is no universal payout table; researchers who assume one program's rates apply everywhere are consistently disappointed. Reading a program's published rewards table before testing, not after finding something, is what separates researchers who target their time efficiently from those who don't.
What are the disclosure rules, and are they legally binding?
Coordinated Vulnerability Disclosure, often summarized by industry-referenced 45-to-90-day disclosure windows (CERT/CC defaults to 45 days; frameworks like Google Project Zero's use 90), is an industry convention that most researchers and vendors informally follow — it is not a universal law, and program-specific rules in the platform's terms of service are what actually govern a given report. Under CVD norms, a researcher reports privately to the vendor, the vendor gets a defined window to patch, and public disclosure (a blog post, a conference talk, a CVE writeup) happens only after that window closes or the vendor agrees. Bug bounty platforms formalize this further: HackerOne and Bugcrowd both require researchers to keep reports confidential until the program owner explicitly authorizes disclosure, and many programs simply never authorize public disclosure at all, regardless of how much time has passed. Violating a program's disclosure terms — publishing before authorization, or disclosing to a third party — is treated as a serious violation on both platforms and can result in forfeited bounties or account bans, separate from whatever general CVD convention a researcher assumes applies.
Why do most first-time reports get closed as duplicates?
Duplicate reports are, by both platforms' own public documentation, the single most common reason first-time submissions get closed as "not applicable" or "informative" rather than paid — and the fix is a research habit, not a skill upgrade. Popular public programs on HackerOne and Bugcrowd get tested by thousands of researchers running the same automated scanners against the same well-known endpoints, so the obvious low-hanging findings (a missing X-Frame-Options header, a verbose stack trace, an outdated JS library flagged by a generic scanner) get reported dozens of times within hours of a program going public. Both platforms operate on a first-to-report basis: whoever's ticket lands first generally wins the bounty, and everyone after gets a duplicate closure with no payout. The practical response is to spend more time on manual, targeted testing of business logic specific to that application — how a checkout flow handles negative quantities, how a multi-tenant app scopes object IDs — rather than running the same three tools everyone else runs against the same three endpoints.
What makes a report survive triage instead of getting rejected?
A report survives triage when a stranger on the security team can reproduce the vulnerability from the write-up alone, without asking the researcher a single follow-up question. That means a clear title naming the vulnerability class and affected component, a precise list of preconditions (account type, authentication state, specific endpoint or parameter), numbered reproduction steps using exact requests or a short proof-of-concept script, and a plainly stated impact — what an attacker could actually do, not just that a technical anomaly exists. Screenshots or a short screen recording resolve ambiguity faster than a paragraph of description. Both HackerOne and Bugcrowd triage teams process a high volume of reports daily, and a submission requiring back-and-forth to even confirm the bug competes poorly for attention against one that's immediately actionable — reproducibility, not novelty, is usually what separates a paid report from a closed one.