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.
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.
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.
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:
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.