Bug Bounty

What is a bug bounty?

A bug bounty is a program in which an organisation invites security researchers to find vulnerabilities in a defined scope and pays them for valid reports. The program publishes the scope (which domains, apps or products), the rules (what is allowed, what is out of bounds, how to report), the severity scale and the reward table. Researchers test on their own initiative and time; the organisation triages the reports, pays for the ones that are new and valid, fixes them and usually allows publication after the fix.

Programs are public (anyone may participate) or private (invited researchers only), run on platforms such as HackerOne, Bugcrowd, Intigriti or YesWeHack or self-managed, and can be time-boxed as a “live hacking event” or continuous.

Where is it defined?

Bug bounties are a market practice, not a standard. The processes around them are standardised: ISO/IEC 29147 describes vulnerability disclosure, meaning how an organisation receives reports from outside and communicates about them, and ISO/IEC 30111 describes the internal handling process from receipt to remediation. RFC 9116 defines security.txt, the file at /.well-known/security.txt that tells researchers where to report. In the EU, the Cyber Resilience Act requires manufacturers of products with digital elements to have a coordinated vulnerability disclosure policy and handling process (Annex I Part II) and to report actively exploited vulnerabilities (Article 14). None of these require rewards. In Germany, the legal position of researchers depends on the program’s permission, which is why clear rules matter: testing without authorisation can fall under section 202a and following of the Criminal Code.

What it means in practice

A bounty is only as good as the team behind it. Before the first payout you need people who triage reports within days, a way to reproduce and rate them, developers who fix them, and a policy on duplicates, out-of-scope reports and researchers who go too far. Companies that launch a public program without this drown in low-quality reports and burn goodwill with the good researchers.

For product and device makers the scope question is harder than for web companies. Researchers need a device to test, test devices cost money, and findings in firmware often need the vendor’s own tooling to reproduce. Hardware bounties exist, but they are rarer and usually invitation-only. A penetration test with authorised firmware extraction and debug access gets to the same places faster.

We do not run bounty programs and do not participate in them for customers; our tests are commissioned, authorised and scoped. We do help with the two things a bounty needs first: the vulnerability handling process (triage criteria, severity rating with CVSS, fix and disclosure timelines, CRA reporting) and the disclosure policy with its security.txt.

Common misunderstandings

A bug bounty is not free testing. It costs rewards, platform fees and, above all, staff time, and the cost is unpredictable. It is also not a measure of security: a program with few reports can mean a secure target or an unattractive one. And it is not a substitute for a disclosure policy. The policy comes first; the bounty is an optional incentive on top.