Setting up a bug bounty programme in your organization
Rootconf For members

Setting up a bug bounty programme in your organization

Experiences from the industry



Organizations of various sizes have been putting together and hosting bug bounties over the years. Some of these are very popular - participants look forward to the event on their calendars. Others, not so much.

The “hit or miss” nature of these events are sometimes a deterrent for any new business thinking about hosting a bug bounty. And yet, it is somewhat easy to plan for success - using playbook-like approaches and strong ownership of the process.

Rootconf invited showrunners of some of the most successful bug bounties to share insights, secrets and tips which will help any business to get started with this approach. Blending talks, how-to’s and panel discussions - this is the one stop shop for how to “get started with bug bounties” that you were looking forward to.

Browse through the blog posts and videos to learn how organizations such as Flipkart, Razorpay and InVideo have thought about and implemented bug bounty programmes.

Participate in the conference to share your work and learn from peers.

About the editorial team

This knowledge repository (blog posts and videos) and conference have been curated by Anant Shrivastava - information security consultant; Shrutirupa Banerjiee, senior security researcher at Quick Heal and Editorial Assistant at Rootconf; and Sankarshan Mukhopadhyay, editor at Hasgeek.

Who should participate

  • InfoSec engineers
  • Appsec engineers
  • DevSecOps teams
  • Security engineers
  • Engineering managers
  • Engineering leadership in organizations

RSVP to participate, or purchase a subscription to access videos, and to support Rootconf’s community activities on

Code of Conduct: Hasgeek’s Code of Conduct applies to all participants and speakers at the meetups.

COVID protocols and masking policy for meetings held in-person: In keeping with COVID protocols, the following is applicable to all participants:

  1. Participants attending the meetups in person must keep their vaccination certificate handy. The venue may ask you to show your vaccination certificate as proof of being fully vaccinated.
  2. Wearing masks is optional.

Contact information: For queries about the meetups, contact Hasgeek at or call (91)7676332020.

Hosted by

Rootconf is a community-funded platform for activities and discussions on the following topics: Site Reliability Engineering (SRE). Infrastructure costs, including Cloud Costs - and optimization. Security - including Cloud Security. more

Shrutirupa Banerjiee

@shrutirupa Author

Prerequisites to creating a bug bounty programme

Submitted Nov 24, 2022

A bug bounty programme can be one of the solutions to maintain a good security culture in your organization. However, building a bug bounty programme can be challenging. Now that we are clear about the importance of the setting up a bug bounty programme, let us look at the essential prerequisites the a company should follow when setting up such a programme.

There are mainly two types of bug bounty programmes:

  • Private
  • Public

Running a private bug bounty programme indicates having a limited number of researchers who can participate. In contrast, a public bug bounty programme allows individuals to participate and submit their reports. To begin with, an organization needs to identify which type of programme they want to go ahead with. If the organization requires more confidence to run a public programme to allow all kinds of researchers to participate, they can start with the private one. Either of the programmes can be run in the long-term; the only difference that it makes is the participation of external researchers. Also, in private bug bounty programmes, only the researchers who have participated will be able to know and work on the scope of the application. Which ever type of programme is chosen, the scope of the application is another aspect that needs to be kept in mind.

What do we mean by the scope of an application?

The researchers participating in the programme are provided limited URLs or APIs that they can test. These limitations define the scope of an application. Researching or finding any bug beyond the scope is not counted as a valid one. An organization holding a bug bounty programme must ensure that the application’s scope is already mentioned in the platform so that only valid submissions are considered.

Once the organization has decided on type of bug bounty programme, it must also decide whether to use an already existing bug bounty platform such as HackerOne, BugCrowd or Intigriti, etc, or build one for themselves. The organization can build its own bug bounty reporting platform if it has enough resources to build such a platform from scratch and maintain it in the future. Evaluating this thought before commencing a bug bounty programme is necessary as there will be a continuous payment or rewards (i.e., bounty) that is given to the researchers, whenever a valid submission is made.

Apart from having enough resources to set up a platform, it is equally important to take care of the process required post submission of a vulnerability. For example, once a submission is made, the first thing is to identify if the submission is valid. What are the criteria for deciding if the vulnerability is critical or informational? In case it turns out to be valid, how will the organization identify payment of bounties to the researchers? What should be the payment method? Will any swag be given to the researchers? The financial aspect/monetary reward should be decent enough to incentivize researchers. The organization must also have a proactive and responsive finance team to take care of payments.

A proper internal security team is not just to test the applications before putting them on the bug bounty platform. They also have a huge responsibility too. The team should promptly take up the responsibility of validating the bug reports, and responding to the researchers as soon as possible. An acknowledgement mail must be sent back to the researchers who submitted any vulnerability. There should also be an appropriate platform for regular conversations with the researchers.

If a valid report is submitted, make sure that the resources to remediate the vulnerability are available too. This means that the remediation infrastructure should already be in place while launching the bug bounty programme.

There can be a scenario where the internal security team has found a vulnerability. In that case, it must be mentioned over the platform that the team is currently working on this issue. The will prevent external researchers from submitting the same vulnerability report again. The same can be mentioned beforehand for out-of-scope and acceptable risk-based scenarios.
An organization ready to host its bug bounty programme is taking a big step towards implementing a healthy security environment. However, certain factors should always be kept in mind. These points may seem quite basic, yet they are important. If not properly managed and organized, the scenarios after launching a bug bounty programme can be highly challenging.


  1. Links to the slides for the talk by Joy B. and Pankaj Mouriya are available here.


{{ gettext('Login to leave a comment') }}

{{ gettext('Post a comment…') }}
{{ gettext('New comment') }}
{{ formTitle }}

{{ errorMsg }}

{{ gettext('No comments posted yet') }}

Hosted by

Rootconf is a community-funded platform for activities and discussions on the following topics: Site Reliability Engineering (SRE). Infrastructure costs, including Cloud Costs - and optimization. Security - including Cloud Security. more