Bug bounty – How can companies benefit from bug bounty programmes?

Bug bounty programmes have recently raised interest and discussion in several companies. A successful bug bounty programme requires high-quality processes from the company throughout the life cycle of the programme. According to our experiences, companies cannot always prepare for the programmes’ challenges and, therefore, the full benefits of the programme are not obtained.

What is needed to create a successful bug bounty programme – what are the programme’s prerequisites, and how much does it cost?

What is a bug bounty?

Bug bounties are programmes, which companies and organisations use to pay hackers for the responsible reporting of information security issues. In this way, companies obtain details of any possible information security problems, and such issues can be intervened. A platform specifically designed for running the programmes is often used, wherein the companies and hackers encounter, for example HackerOne.

In the programme, the organising entity, i.e., the company or organisation, creates rules that specify the services within the scope of the programme and the rules according to which each subject can be tested. The organiser specifies the remuneration, also known as bounties, to be paid to the hackers and the publicity or privacy of the programme. In a public programme, anyone can participate in the testing and report observations. On the other hand, in a private programme, only specific individuals are invited to test the service.

Processes in order

A successful bug bounty programme requires preparations to be carried out by the organisation arranging the programme. It is not sufficient to register for the service offering the platform and publish a programme there. When reports begin to flow in, how can they be reacted to so that the problems can be fixed? Has the scope of the programme been considered? Who communicates with the hackers, analyses the criticality of the observations, verifies the accuracy of the observations and decides the amount of payments?

Before a bug bounty programme is published, a sufficient level of information security should be verified. The services within the programme’s scope are worth testing before the programme is published, and any known information security issues should be fixed because otherwise, the programme and the assessment of costs will be impossible in principle, and there will be an overwhelming number of observations submitted by the hackers. Therefore, a sufficient level of maturity should initially be ensured in terms of information security, and the security situation of the relevant systems should be known.

When initiating a bug bounty programme, it is crucial to always get processes and operating methods in order. An answer to at least the following points should be found:

  • Has the scope of the programme been created and verified?
  • Have the rules of the programme been considered and created?
  • Will the programme be public or invitation-based?
  • How much is intended to be paid for observations?
  • Who will monitor the observations made by hackers and communicate with them?
  • Does the organisation have the skills to verify the accuracy of the reported observations, and who will do this?
  • Who assesses the criticality of observations? What criteria are applied?
  • How are observations communicated to application developers?
  • Are there other entities who should be informed about the programme or from whom permits are required – for example, providers of capacity services (Amazon, etc.)?
  • How is it verified that the reported issues are fixed correctly?

It is imperative that these issues have been considered and verified before the publication of the bug bounty programme because otherwise, the programme will not provide much benefit. In the worst-case scenario, risks are caused if, for example, issues are not agreed upon in advance with capacity service providers. Before publishing the programme, it is also important to ensure that the service’s business objectives are not placed at risk and that, for example, the availability of the service is not at risk. In this regard, this requires more efficient supervision and the monitoring of availability.

Do bug bounties offer a shortcut to happiness?

In order to raise interest in the most skilled hackers, a bug bounty programme must be sufficiently attractive to hackers – remuneration must be competitive, and the scope must be sufficiently comprehensive. This obviously increases the costs of the programme. It is also worth considering that the number of top hackers is limited while a large mass consists of lots of parties using automatic tools and are after an easy source of money. Communication with these parties can require a surprising amount of time, even if the said parties don’t provide significant added value to the company.

One of the biggest challenges of a bug bounty programme is the difficulty in predicting costs.

We have realised that our customers encounter major challenges to fix reported observations. In terms of the organising party, the most important objective is to improve the information security of the services within the programme’s scope, which unfortunately often is not fulfilled. If this does not occur, the money and resources spent on the programme are wasted.

Thus, one of the biggest challenges of a bug bounty programme is the difficulty in predicting costs. It is worth noting that the costs are not just limited to the payments paid to the hackers – the application developer will also invoice for rectification, and the use of personal resources also costs. A good rule of thumb is that the amount paid as remuneration can be multiplied by at least two to obtain a rough estimate of costs. For example, if the remuneration is paid in the amount of 20,000 euros per year, the total costs, in this case, would be 40,000 euros. Therefore, it can be stated that bug bounty programmes do not offer a shortcut to happiness in finding vulnerabilities. Still, the programme allows information security issues to be made aware, which would not have been found in, for example, standard information security testing.

And the benefits?

Although running bug bounty programmes often requires financial efforts and resources from the organising entity, a well-organised programme offers enormous benefits. The programme may provide observations, which have not been observed during regular audits because an individual hacker may spend a significant amount of time finding an individual observation. Audits do not usually, schedule-wise, allow such in-depth searches for one vulnerability.

The programmes also offer organisers a great benefit in cases where the annual information security testing does not provide sufficient certainty. If, for example, new publications of the service are made on a daily basis, testing that is carried out annually is relatively quickly out-of-date. In this case, a bug bounty programme can be used to test the system 365 days a year, and payment is only made for submitted observations.

In addition to finding vulnerabilities, well-implemented programmes provide added value to the brand, and they can have a positive influence on the company’s image as well as help in the recruitment of professionals. Thus, the benefit of programmes is not solely limited to improving the company’s information security, but they also have many advantages in terms of communications.

Audit or bug bounty?

These two should not be considered as options that exclude each other. If only one of these is an option, auditing or information security testing provides a better overview of the entity and the repeated testing process, which is carried out by a professional. Unfortunately, these cannot be guaranteed for a bug bounty programme, nor can it be ensured that the system has been professionally tested.

If the organisation has sufficient resources and maturity, a bug bounty programme provides more in-depthness alongside audits. However, regular information security testing is needed to verify the basic level of services’ information security – in this case, costs are also significantly easier to estimate. If a decision is made only to implement the bug bounty programme without information security testing, significant risks shall apply in the form of excessive costs. In this case, there is also no understanding of the services’ information security level or the existing vulnerabilities, and the hackers can achieve several easy hits – and to ensure that the programme is credible, payments must be paid for these observations.

How do we provide added value to your bug bounty programme?

2NS helps its own customers to launch and run bug bounty programmes. We help the customer to, for example, verify that the necessary processes of the bug bounty programme are in order before the launch of the programme. We also provide help with analysing and verifying observations and communicating with hackers. Please contact us, we will help you assess the sensibleness and possible risks of the bug bounty programme, and we will operate as your partner while launching and running the programme!