Why Bug-Bounty hunters cannot be Security testers?

In a recent incident involving Facebook’s Bug Bounty program, there was a sudden rise of many different reactions, supporting both Facebook and the security researcher’s community. Regardless of who was actually responsible for this case, one fact was clear that; the researchers went too far, beyond the initial expectations of the social media firm, eventually getting access to their sensitive data. This was something unexpected by the company itself!

So there arises a big question. Are Bug-Bounty hunters really reliable and professional?

I’ll start this by pointing out the basic difference between a security tester and a bug-bounty hunter. The difference lies in the intent and the access rights given to them, as one is considered authorized and the other is practically unauthorized.

The recent Zomato hack is a perfect example of an unethical or unauthorized hack, where the hacker involved was responsible for provoking the company to run a bounty program, which eventually resulted in the leakage of millions of user data. Most companies don’t trust an independent individual with their security regulations, they instead prefer an established security firm for their audits.

The next question that arises is, why don’t firms hire bug bounty hunters as regular employees instead of exploiting them as contractors?

This is the reason why Uber, the world’s largest taxi company was in court two years back, for bearing charges of exploiting people and ultimately harming the economy and the middle class in general, by not offering its workforce the benefits of employment.

There exists a misconception that, bug bounty can seriously reduce the vulnerability testing costs as you pay only for results. For the majority of cases, this assumption is totally wrong, as a poorly-implemented Bug Bounty will just ruin your relations with the security community and create a bad reputation for your company.

Bug bounties have certain disadvantages we need to clearly understand:

  1. Very few researchers will fully read or respect your bug bounty guidelines and conditions when you specify certain criteria for vulnerability submission.
  2. Bug bounty cannot replace continuous monitoring of your web infrastructure, as they perform tests whenever and however they want.
  3. Bug bounty cannot serve as an additional protection layer to your web infrastructure, as they primarily aim to find vulnerabilities and not to patch them or prevent their exploitation.
  4. They are also not suitable to test your private systems as you simply cannot involve risk in any of your company data. Even if you function via a managed bug bounty program, you won’t achieve the same level of financial authenticity, financial insurance, compliance, liability and personnel clearance as you may expect from a professional penetration testing company.

Therefore, even though the professional methods seems bit traditional, just keep in mind that, If you are launching a bug bounty program, you should have enough technical and human resources to handle, analyze and properly follow-up the avalanche of submissions that you are likely to receive, as every single submission needs to be properly answered in a timely manner.

The testing methodologies and requirements should be proportional to your web infrastructure and its expected usage in production. Therefore, if you are a large scale company with a huge number of publicly facing web applications that are open to anyone and designed for everyone, a bug bounty program can definitely be a great added-value to your existing security methodologies.

Otherwise, you should better be concentrating on the main risks to web applications, and rather spend your security budget on traditional web security services and solutions that are more suitable to your business needs and technical requirements.

Leave a Reply