A bug bounty is a program in which an organization invites outside security researchers to look for vulnerabilities in defined systems, such as websites, apps or APIs, and pays rewards for valid, responsibly reported findings. Programs set out what is in scope, how researchers may test, how to report and how much each type of finding is worth. Many are run through bug bounty platforms that recruit researchers and help triage reports, though some organizations run their own.
At a glance
- Bug bounties pay for results: rewards go to valid, in-scope findings, usually scaled by severity.
- Programs can be private (invited researchers only) or public (open to anyone who accepts the rules).
- Clear scope, testing rules and safe harbor terms are central to running one safely.
- A bug bounty supplements penetration testing and internal testing; it doesn’t replace them.
- It only pays off if you have a process to triage, fix and track reported issues.
What problem it solves
Organizations with public-facing software face attackers who keep probing it, while internal teams and annual penetration tests can only cover so much. A penetration test is a scheduled engagement with a small team for a limited time; new code shipped the following week isn’t covered until the next test. Meanwhile, independent researchers may already be finding flaws and have no clear, safe way to report them.
A bug bounty taps a large pool of researchers with different skills, who can test throughout the program and are paid only when they find something real. It also gives a formal channel for reports, so issues come to you instead of being published or sold. Combined with a published vulnerability disclosure policy, it tells researchers you welcome good-faith reports, which many customers and some regulators now expect from software providers.
How it works
Scope and rules. The organization defines which assets are in scope, what testing is prohibited (for example denial of service, social engineering or accessing other users’ data), and how findings must be reported. Safe harbor language describes how good-faith research will be treated; have counsel review it, as laws vary by country.
Rewards. A reward table sets payouts by severity, often from small amounts for low-risk issues to larger rewards for critical flaws. Duplicates usually go to the first reporter only.
Researcher access. In a private program, the platform or organization invites vetted researchers. In a public program, anyone can participate after accepting the terms.
Triage. Reports are checked for validity, duplication and severity, either by the organization or by the platform’s triage team, then passed to the right engineers. Fast, respectful communication keeps researchers engaged.
Remediation and tracking. Valid issues are fixed and tracked through vulnerability management processes. Where the flaw is in a product others use, it may be published as a CVE after it is fixed.
When it matters for buyers
- When you build and run customer-facing software. Web apps, mobile apps and APIs are typical bounty targets, and a bounty fits alongside the testing covered in our application security testing overview.
- When researchers are already contacting you. A clear process is better than ad hoc emails.
- When customers ask about vulnerability disclosure. Enterprise and public-sector buyers increasingly expect a published policy.
- When you ship code frequently. Researchers can test new releases while the program runs, though which assets they test, and when, is not guaranteed.
- When your attack surface is large. Outside researchers often find forgotten assets; attack surface management helps you find them first.
Questions to ask vendors
- Do you offer private and public programs, and how do you vet invited researchers?
- Do you provide triage, and what is your target time to validate a report?
- How are platform fees structured, and how are rewards budgeted and paid?
- What legal terms and safe harbor language do you provide, and can our counsel adjust them?
- How do you handle duplicate, out-of-scope and low-quality reports?
- Can findings flow into our ticketing and vulnerability management tools?
- Do you also run a vulnerability disclosure program without payouts?
How it differs from penetration testing
Penetration testing is a scheduled engagement: you hire a firm, agree scope and dates, and pay for the testers’ time, whether or not they find serious issues. It produces a structured report that is often used for compliance. A bug bounty runs for as long as the program is open, with many independent researchers who can test throughout it, pays only for valid findings, and produces individual reports as issues are found, but gives less predictable coverage and isn’t usually accepted on its own as a formal test. Red teaming goes further than either, testing whether your team can detect and respond to a realistic attack. Many organizations use pen testing for scheduled, scoped assurance and a bug bounty as an additional, ongoing source of findings, without relying on it for guaranteed coverage.