Are we too small for a bug bounty?

For a paid program, probably yes until you have 1-2 dedicated security engineers and 500+ paying customers. For a VDP with recognition-only (no payouts), any size — publish one before your first pentest, not after your first incident.

HackerOne or run it directly?

Platforms (HackerOne, Bugcrowd) handle researcher payments, KYC, dispute mediation, and researcher pool access. Direct programs skip the platform fee (usually 20% on top of payouts) but require you to build all of that infrastructure. Platforms win for most companies until you're spending $500K+/year on bounties.

What if a researcher finds something and demands a bigger payout?

Publish the payout table up front and stick to it. Case-by-case negotiation encourages every researcher to negotiate, which corrodes the program. Adjust the table over time based on market rates; don't renegotiate individual reports after the fact.

Bug Bounty Program: Scoping, Payouts, and Running a Program

A bug bounty program invites external security researchers to find and report vulnerabilities in your product in exchange for monetary rewards.

Bug Bounty Program: Paying Ethical Hackers Beats Paying Post-Breach Consultants

A bug bounty program is a structured invitation to external security researchers to find vulnerabilities in your product and report them responsibly, in exchange for cash payouts and public recognition. HackerOne, Bugcrowd, Intigriti, and YesWeHack are the major platforms; large companies also run private programs directly. A well-run bounty program is one of the highest-ROI security investments a growing SaaS can make; a badly-run one wastes engineering time and can damage relationships with the security community.

Vulnerability disclosure policy first

Before a paid bounty, publish a Vulnerability Disclosure Policy (VDP) — a page at /security or security.txt telling researchers how to report vulnerabilities safely, what testing is allowed, and what your response commitment is. VDP is table stakes and free; it converts researchers from 'hostile stranger poking your app' to 'partner following your rules.' CISA and many governments now require VDPs for their vendors. Getting the VDP right is a prerequisite for a paid bounty — running a bounty without a coherent disclosure policy generates chaos.

Private vs. public programs

Private programs invite a curated list of researchers (10-100), tighter scope control, less noise, easier to start. Public programs open to any researcher, larger volume, more diversity of findings, more noise to triage. Standard progression: VDP → private bounty program (6-12 months to tune scope and processes) → public program. Jumping straight to public with an unprepared triage team produces a backlog that damages your reputation with researchers who report and get no response.

Scope and out-of-scope

Explicit scope prevents wasted researcher time and wasted triage time. Include: which domains and apps are in scope, what testing is allowed (no DDoS, no social engineering, no testing against other customers' data), what data is safe to demonstrate (test accounts only). Explicit out-of-scope: rate-limit issues, missing HTTP headers of low impact, self-XSS, third-party services you don't control. Programs with vague scope generate a stream of low-value reports; programs with clear scope generate meaningful findings.

Payout ranges that attract real researchers

Payouts should match your security stakes. Typical B2B SaaS ranges: Low ($100-500 for informational or low-impact bugs like missing CSRF on a low-value endpoint), Medium ($500-2K for meaningful issues like authenticated IDOR), High ($2K-10K for RCE, auth bypass, data leaks), Critical ($10K-50K for widespread impact vulnerabilities). Under-paying attracts no experienced researchers; over-paying against your revenue is unsustainable. Benchmark against public programs at similar-stage companies via HackerOne's Hacktivity feed.

Triage discipline

The single biggest reason bounty programs fail: slow or dismissive triage. Commitments researchers expect: acknowledge within 24-48 hours, initial validation within 5 business days, resolution timeline for accepted issues, prompt payment upon fix. Response-time reputation is public on bounty platforms; slow programs get downgraded and stop attracting good researchers. Budget 2-8 hours per week of security engineering time for triage; if you can't commit that, run a VDP without payouts instead.

Frequently asked questions

Are we too small for a bug bounty?: For a paid program, probably yes until you have 1-2 dedicated security engineers and 500+ paying customers. For a VDP with recognition-only (no payouts), any size — publish one before your first pentest, not after your first incident.
HackerOne or run it directly?: Platforms (HackerOne, Bugcrowd) handle researcher payments, KYC, dispute mediation, and researcher pool access. Direct programs skip the platform fee (usually 20% on top of payouts) but require you to build all of that infrastructure. Platforms win for most companies until you're spending $500K+/year on bounties.
What if a researcher finds something and demands a bigger payout?: Publish the payout table up front and stick to it. Case-by-case negotiation encourages every researcher to negotiate, which corrodes the program. Adjust the table over time based on market rates; don't renegotiate individual reports after the fact.