Bug bounty program design
A well-designed bug bounty program turns the global security research community into an extension of your team. This recipe walks you through scoping, pricing, and operating a program that surfaces real vulnerabilities without drowning your engineers in noise.
1. Define scope and rules of engagement
Scope is the single most important lever. List the exact domains, mobile binaries, and API endpoints that are in scope. Explicitly call out what is out of scope: staging mirrors, third-party SaaS, social engineering, denial-of-service. Publish a safe-harbor clause so researchers know they will not be prosecuted for good-faith testing.
- Production web app at app.example.com
- Public API at api.example.com (v2 and later)
- iOS and Android mobile clients (latest two minor versions)
2. Price by severity, not by report volume
Pay against CVSS bands with a published table. Researchers triage themselves toward higher-impact bugs when the rate card is transparent. A canonical starting structure:
severity cvss bounty (USD) critical 9.0 - 10.0 $5,000 - $20,000 high 7.0 - 8.9 $1,500 - $5,000 medium 4.0 - 6.9 $400 - $1,500 low 0.1 - 3.9 $100 - $400 informational swag or hall of fame
3. Operate the intake queue like a product
Bounty programs fail on operations, not on policy. Commit to a first-response SLA of under 48 hours, a triage decision within five business days, and a payout within thirty days of confirmation. Route reports into the same issue tracker your engineers already live in, with a dedicated label and an on-call rotation. Publish a quarterly transparency report listing bug counts, total paid out, and median time-to-fix so the community trusts the program.