A bug bounty program is a managed administrative mechanism for reporting bugs to organisations involved in software development.Whilst any software bugs could be reported, in practice, bug bounty programs are normally focused on the discovery of security vulnerabilities and exploits. Many programs provide recognition and, sometimes significant, monetary compensation for security researchers who discover previously unknown issues.
These programs provide ‘permission’ for specialists from outside the organisation to carry out research and discover bugs which can be resolved before they become public knowledge, potentially preventing widespread abuse.
Bug bounty programs have been implemented by many well-known organisations, including Facebook, Google, Microsoft, Mozilla and Tesla. Even some government organisations now use bug bounty programs as part of their on-going security risk reduction efforts.
If you believe that your organisation could benefit from a bug bounty program, follow the steps below to get you started on the right path to building your own successful program.
Launch a program without monetary incentives
Set up a well-defined vulnerability disclosure process so that outsiders can use to safely report security findings to your security team. Starting with a non-payment program will attract fewer participants and will allow you to launch the program at a smaller scale. This will help your security and development teams to get the feel of receiving input from people outside the organisation.
This first step is important because it will provide insight to some of the potential complexities and issues that may be present in a full-fledged bug bounty program, such as how to respond to the disclosures, the escalation process, and challenges with remediation.
Carefully Draft and Communicate the Scope and Rewards Available
Clearly defined the rules of your bug bounty program for all participants. Clear communication helps ensure that your organisation gets what it wants out of the program and that the participants are satisfied because they will have accurate expectations of the process and any payments. The most important things to define are:
Program scope: What kinds of bugs are you looking for? Are there parts of the infrastructure (application or network) that are off-limits such as targets that may affect the availability of live system?
Rewards: How much you pay for reported bugs needs to balance two factors. First, it must match or exceed their value on the black market. You clearly want your researchers to report their findings to you, not to criminals. The program must be also be affordable to run and give a return on investment.
Decide whether your program will be Public or Private
The more researchers that have access to your program, the more bug reports you are going to get. That may sound like a good thing, but there is also an overhead with a large program. More reports mean you have to provide more responses, assess and validate more findings and manage payments to more individuals.
With a public program there will be more network activity and endpoints to manage and more work to determine whether it is legitimate bounty hunters or malicious actors. A public program where anyone in the world can participate takes many more resources to conduct than one with a limited number of participants that have been carefully vetted through an application process for a private program.
Create a separate test environment for the program
Set up an isolated, segregated, test environment for the bug bounty program. It should not have any links to the organisation’s production or other development and test environments.
Make sure that the test data is unique to the bug bounty test environment. You should not have accounts or data copied directly from other development or test environments to mitigate against the risk of them being used for malicious purposes. By using live data, you could turn your bug bounty test environment into a reconnaissance playground for attackers.
Plan for change freezes
You may have periods when you do not want outsiders testing your code and quiet periods following bug discovery to ensure resolution before the bug is made public. Changes/updates may also require time for internal due diligence activities before being made available for public testing.
Be sure to cater for normal change-freeze windows, and product release lifecycles. This will help minimise the impact to the other development and test environments and allow the business and development to dedicate more time to key business changes.
Get support from the business hierarchy
An effective bug bounty program will involve many organisational departments. It needs the executive team to provide financial support for administration and bounty payments. It will need legal support for writing contracts, such as those that define the program and the company’s relationship with participants. It needs the Development Team to incorporate bug fixes into new software versions and the Security Operations Team to monitor participants activities.
For a bug bounty program to be effective, the organisation needs enough technology and administrative staff to support it. The IT team or Information Security team may not have availability to support a full-time bug-bounty program in addition to their business-as-usual responsibilities.
Make sure you have identified the support you will need and have the buy-in at all level of the organisation or the program will not succeed. If you do not have the resources to be able to respond and fix reported bugs, you are not ready to launch a bug bounty program.
Manage communications
If the bug bounty program is made public, it must be marketed and focussed on attracting the right kind of participants. Identify websites, and other communication channels security researchers will see and communicate to them in a way that attracts the curiosity and problem-solving skills of the best talent.
Once the program is under way. Communicate regularly with participants to keep them abreast of any changes, success stories and reminders about compliance with the rules of participation.
Consider a Third-Party Program
As with all business processes, particularly no-core activities, outsourcing is one option to consider. If you wish to start or expand a smaller bug bounty program you could look at using a specialist company to run it such as Bugcrowd.
Whichever way you choose to start it, we wish you good luck with your bug bounty. The key point to remember that unless you are fully committed to your program and to providing the resources to respond to the issue that your program will uncover, you should wait until you are in that position before starting your program.