What Is Bug Bounty?

A bug bounty programme invites independent researchers to find and report vulnerabilities in exchange for payment. It provides continuous testing by many people with varied approaches, which is a different shape of assurance from a scheduled engagement.

It is not a substitute for penetration testing. Bounties reward findings, which means researchers concentrate on what is findable and rewarded rather than on systematic coverage.

What it adds that a scheduled test does not

Continuity, because testing happens all the time rather than during a window. Diversity, because many people with different specialities look at the same target. And economics that favour you — payment on results rather than on days.

It is particularly effective on large, frequently changing internet-facing applications, where a point-in-time test is stale within weeks.

What it does not provide

Coverage assurance. Nobody can tell you what was examined and found clean, only what was reported. Testing of areas that are hard to reach or unlikely to yield a payout. And any assessment of the systems researchers are not permitted to touch.

Compliance requirements that specify periodic testing are generally not satisfied by a bounty programme, for the same reason.

Triage is the real cost

The expense is rarely the payouts. It is the staff time spent handling submissions, a substantial share of which are duplicates, out-of-scope reports, automated scanner output or findings with no real impact.

Response time matters to researchers, and a programme that responds slowly loses the good ones. Budgeting for triage capacity before launch is what determines whether the programme works.

Scope, rewards and safe harbour

Scope should name what is in and what is explicitly prohibited — denial of service, social engineering, testing against production data, anything touching third-party services.

Rewards should reflect severity and be competitive enough to attract attention, since researchers choose where to spend time. And legal safe harbour, stating clearly that good-faith research within scope will not be pursued, is what makes people willing to participate at all.

A disclosure policy comes first

Even without a bounty, every organisation needs a published route for reporting a vulnerability. Researchers find issues whether or not you invite them, and the alternative to a clear channel is disclosure through social media or nothing at all.

A short published policy with a contact address and a commitment not to pursue good-faith reporting costs nothing and is the baseline this whole category rests on.

Researcher relations and severity disputes

Disagreement about the impact of a finding, and therefore its payout, is the most common friction. Published severity criteria and a stated appeal route prevent those becoming public arguments, which they otherwise do.

Response quality matters beyond payment. Acknowledging quickly, explaining decisions and crediting researchers who want it costs nothing and determines whether capable people keep looking at your systems. A programme with a reputation for slow or dismissive handling attracts only automated submissions.

Where to start

Publish a vulnerability disclosure policy with a contact address and safe harbour language. It takes an afternoon and it is useful whether or not you ever pay a bounty.

See penetration testing. GuardsArm delivers application penetration testing.