Setting up a bug bounty programme in your organization

Starting a bug bounty programme may seem like an enormous task. Regardless, if it is properly planned and managed, it becomes quite easy to implement. Each team should be well aware of its roles and responsibilities.
After having seen how to start a bug bounty program, I’ll walk you through some important suggestions that should be kept in mind while running the bug bounty programme.

As mentioned above, each team is important and has a responsibility to obey. The teams should be prepared for their set of tasks whenever a vulnerability is reported by a researcher. Starting from sending an acknowledgment mail to communicating with the researcher to mitigating the vulnerabilities, and paying the bounties on time, each step is crucial to a successful outcome of a bug bounty program. After a vulnerability is reported, it is the responsibility of the respective internal security team to communicate and send updates to the researchers. A time frame should be decided within which the respective team should respond to the researcher. This will give an idea to the researchers too as to whether to wait for the team’s response or move on with their next set of tasks.
A communication gap may result in a lot of discrepancies which may create an issue for both the researchers and the organization. The entire flow should be transparent and well followed.

In case a casualty is observed in any step, the researcher should be notified immediately along with an apology mail from the respective team.
The team should work on improving and enforcing the corrective action to it so that it does not happen in the future again.

I’ll move on to some concluding remarks about the Do’s and Don’ts of running a bug bounty programme.

Don’ts

• Publishing non-tested assets on programmes - each and every application - APIs, URLs - should be well tested by the internal security team before putting them under the bug bounty programme. The programme should be based on finding extremely difficult vulnerabilities which were not covered by the internal team.

• Not defining the scope of the programme - the scope of the programme should be clearly defined on the platform so that the researcher can focus on the required URL or API. Anything other than that, should be considered out of scope.

• Not maintaining the program periodically - the team should keep a periodic check on the platform if there is anything else that needs to be added or removed from the website. Is there any new information that should be added for the researchers? Or, is there any bug within the platform itself which should be remediated as soon as possible?

• Taking conversation with the researchers personally - during the bug submission process, there can be a conflict between the researcher and the internal security team. Such conflicts should not be taken personally and should be handled professionally and politely. Any wrong or careless step may affect the application and the programme along with the reputation of the organization.

Do’s

• Maintaining good vibes with the researchers - it is extremely important to maintain a good vibe with the researchers as they are the ones who can find vulnerabilities which were missed by the internal security teams. The process that these researchers have followed might be help the organization to look for similar bugs in any other unpublished applications.

• Connecting with the researchers on timely basis - it is the duty of the internal security team to regularly connect with the researchers and provide the updates related to their reports. A good and timely communication between the researchers and the respective team can help in mitigating the vulnerabilities sooner.

• Providing as much transparency to the researchers as possible to build their trust - the researchers should also be given all the details and updates related to the report that they have submitted. Transparency in such scenarios can help the researchers believe in the authenticity of the platform and the organization’s process.

• Automating the bug submission process at the company’s end - an organization should always keep upgrading and enhancing their applications/platforms. The initial phase may look tricky. However, the later processes should be improved and automated with time. The art of maintenance is one of the reasons behind good and successful bug bounty programmes.

Of course, there will be a number of flaws before a proper and an organized programme is run into implementation. Each organization needs to check how many flaws and problems it can realistically consider and manage, and if there is any issue, how is it being solved by the respective teams. The ultimate goal is upgrading the current process with time along with maintaining it.