Bug bounties are a powerful tool to leverage the security community and researchers to find vulnerabilities in your applications. For the vast majority of companies, we recommend starting with a limited scope bug bounty program on a managed platform, scoped to non-prod environment created specifically for the bounty program. Using a dedicated environment with non-prod data (ideally one built specifically for the bug bounty program) means customer data won’t be disclosed if there’s a critical bug and it means your daily operations won’t be impacted if there’s any sort of bug that breaks your application.

We recommend against using a bug bounty as your primary bug discovery method. Before opening a bug bounty program, use internal (or partner) resources to perform basic scans, threat modeling, and security assessment of your application. This helps decrease the volume and increase the quality of bug bounty submissions when the program goes live, which creates less work for your team.

We also caution customers that bug bounties do not solve the same problem as a true red team (attack simulation) or a well-scoped penetration test. However, bug bounties do have an important place in a modern security program when used appropriately.

Using a bug bounty platform like HackerOne or BugCrowd to interface with researchers reduces the burden on your team and makes for a “tamer” bug bounty program. Check out Building a Modern Security Program by Zane Lackey and Rebecca Heuhls which has some great info on running your own bug bounty (without a moderated bug bounty platform).

Below is guidance from our direct experience running bug bounties with customers, and conversations with customers and industry peers.

Activity Cost Scope Skill Result
Penetration Testing Varies Customer sets scope Varies ($) Vulnerabilities
Attack Simulation High Full (phishing, old infrastructure) Intentionally varied Attack paths
Bug Bounty Low Attacker chooses from limited scope Unknown Vulnerabilities
  • Clarity, quality, and volume of reports will vary dramatically over time and across submitters. A bounty platform should handle this.
  • Prepare for lots of scanners against your site when you first turn it on. Consider policies to discourage automated scans and high traffic activities, such as limiting the number of submissions per researcher per day so that they’re prioritizing quality over quantity.
  • Consider creating a separate test environment and scope only to that for the bug bounty.
  • Create explicit bug class exclusions e.g. cookie flags, click-jacking, DOM-based XSS with no demonstrable impact, or you will be expected to pay out for these bugs.
  • Prepare the escalation/remediation process prior to turning it on. Includes “bug bar” impact scale, SLA/bug fix timing, and communication with bug submitters.
  • Prepare for the potential for submitters to feel slighted (lower than expected bounty awards, miscommunications, etc) and publicly air their grievances. Consider fallbacks if you decide not to pay out a bounty for any reason. Shirts and mugs are cheaper than bad publicity.
  • Consider opening up the program bit by bit, or by invite or high reputation score initially.
  • If your application is complex or interacts with multiple out-of-scope components, work to define a very clear scope, perhaps with architectural drawings and lots of verbosity.
  • The higher your bounties, the more traffic you’ll get. Consider what types of vulnerabilities you’re looking for and modulating your bounties to encourage/discourage traffic.
    • Especially in the beginning, you may not need to pay out as much to attract attention if you’re expecting lower hanging fruit bugs.
    • Higher bounties will attract more skilled and experienced bug bounty hunters if you’re expecting harder to find bugs.
    • This also depends on how you’ve opened the program (public or private). Avoid targeting more experienced bug bounty hunters while providing below-market bounties
  • Consider what you will do if you reach your bounty budget for total payouts, or if you get too much traffic to handle remediations and communications (or if other priorities take up engineering time unexpectedly). Pause the program? How will you handle in-flight reports?

Disagree? Ready to run a bug bounty or curious if you’re ready? Give us a call. We look forward to your feedback.