With Apple's recent announcement about starting its first Bug Bounty Program this September, it raises the issue of why they waited so long and why they did finally did decide to create one.
Bug Bounty Hunter (BBH) programs are relatively simple in theory - security professionals or hackers who find security holes receive compensation based on the criteria defined in the program. A well-managed program can be a valuable component of a mature software development lifecycle; however, a poorly-organized one can generate a lot of headaches and effectively paralyze an entire security team as they sift through the findings.
On one hand, bug bounty programs are performance-based; so, you only pay when results are attained. They can also help organizations get informed of critical vulnerabilities that might otherwise remain undiscovered. Many hackers will work very hard to earn the rewards (and potentially bragging rights) for finding juicy vulnerabilities and exploits.
On the other hand, these programs can backfire, especially when the program isn't clearly defined. Some common problems include:
- Forgetting to omit vulnerabilities already known to the organization
- Trusting a hacker will find a security hole and not exploit it for their personal gain (especially if that gain is significantly greater than the award.)
- Not fixing public/known vulnerabilities which can anger a crowd-source community.
- Not adequately defining vulnerability criteria, e.g., if a hunter finds multiple SQL injection issues accessing the same routine, is that considered multiple vulnerabilities or just one?
- Reproducibility requirements to validate reported vulnerabilities (and pay the hunter upon validation.)
- Dangers associated with destructive vulnerabilities. XSS and SQLi bugs might disrupt service or destroy data tables.
Before rolling out bug bounty program, companies should seriously consider whether their organization can handle all the vulnerabilities found by the public. Also important to consider is whether the bugs can be fixed in a timely manner – potentially at both the design and code levels. Since bug bounty programs focus on finding the problem vs. the root cause or fix, they can bring a lot of scrutiny to a company’s software applications. This is why I believe these programs are best suited for more mature organizations that can address the problems found, spend time defining vulnerability criteria, and have a structured communication strategy around the program.
