In the past several years, bug bounties have evolved from the open-to-everyone contests they once were, becoming more nuanced with the ability to meet various organizational goals and objectives. While some reasons for starting a bug bounty program may be more obvious than others, there are multiple business goals or drivers that organizations, including your own, may identify when looking into launching a bug bounty program.
Those objectives or drivers will dictate how your program is run–what is being tested, how it’s tested, and who’s testing it. In this post, we will address four common business objectives for running a bug bounty program, the solutions to meet those goals and considerations in setting up and managing your program to optimize for that business outcome.
#1: Better Security Testing
Problem to solve: I know I need to bulk up our organization’s security, either across the board or on specific products.
Solution: Bug Bounty Program
This is the most obvious reason for launching a bug bounty – to uncover more unknown vulnerabilities and implement better security best practices. Our customers run private or public bug bounty programs to achieve this goal, incentivizing the security researcher community with cash rewards for finding valid vulnerabilities. The type of application in question and/or the desired testing scope will dictate which type of bounty program is best suited.
#2: Application Testing Prior to GA
Problem to solve: I need to have a quick test done before launching an application to GA.
Solution: On-Demand Program
Similar to running a penetration test, a crowdsourced application test is a great way to get quick testing done with optimal results. What is an On-Demand program? Bugcrowd’s on-demand bounty programs deliver hackers on demand. Time-boxed for up two weeks, these capped-cost engagements are useful for testing new products, major releases, new features, or anything that needs a quick test.
These programs are also excellent starting points for eventually running a bug bounty program. With Bugcrowd, an on-demand program can easily be brought into a broader ongoing program as people are already familiar with it, and any issues found during on-demand testing will already be in the platform. Once fixed, researchers will get a notification and likely test to confirm the fix.
Further considerations: If your organization is not used to consistent vulnerability feedback, the volume of submissions could lead to a delay in GA. This is a great problem to have, as your product will be more secure than it would have been otherwise, and you may have saved yourself a lot of time and resources further down the line, but it should be kept in mind, as not everyone internally will realize this initially.
#3: Channel for Vulnerability Reporting:
Problem to Solve: People I don’t know are emailing my organization to report security bugs and no one knows what to do.
Solution: Responsible Disclosure Page
As your product gains popularity and traction, it is inevitable that the security research community will start poking around. For smaller organizations just getting started in security testing on the application level, this can be a learning process.
Many organizations ramping up their vulnerability feedback and remediation channels and loops utilize a responsible disclosure page as a proactive first step. Giving security researchers a channel through which they can communicate potential security flaws achieves multiple goals:
Strengthens relationship with security research community–we provide feedback on the researcher’s performance record if they participate on our platform.
Consolidates all channels for vulnerability receiving so you can easily track and process any submissions and/or new researchers who want to contribute, as well as track the submission through the development process to resolution.
A good starting point to work with engineering or development teams to understand security flaws, prioritize with existing workloads and remediate appropriately
Problem to solve: I want to show the security research community that our organization takes security seriously and/or be a leader in our industry/sector to launch a bug bounty program.
Solution: Public Bug Bounty Program
This commitment to security can be a great way to have an edge over competition, position oneself as a thought leader amongst peers, or in general, gain points with the security research community.
In this post we reviewed just a few of the common reasons organizations run crowdsourced application security programs. Additional reasons include handling controlled events such as one-off vulnerability disclosure events, fulfilling compliance checkboxes, replacing penetration tests, and more.
To learn more about these goals and how our customers meet their goals through bug bounty programs, watch our webcast ‘The Bug Bounty Tipping Point’ we held earlier this week.