Bug bounty management, a great example: Zomato

Since I decided to work on my advisor position in the bug bounty industry, I wanted to know more details about what makes a good program, what are the important keys and what to avoid.

I contacted Prateek Tiwari, lead security engineering at Zomato, he was nice enough to answer all my questions. Let’s discover how Zomato became one of the best program, not only on Hackerone but in the whole bug bounty industry.

Can you introduce yourself please?
I’m Prateek Tiwari from India and I go with my handle @prateek_0490 on all platforms. Been into hacking for about 2.5 years now. I started working with Zomato from Mar'18. Here, I’m responsible to lead the security engineering team to develop a common solution and infrastructure.

Can you shortly describe Zomato?
Launched in Delhi 11 years ago, Zomato has grown from a home project to one of the largest food aggregators in the world. We are present in 24 countries and 10000+ cities globally, enabling our vision of better food for more people. We not only connect people to food in every context but work closely with restaurants to enable a sustainable ecosystem.

How many people are you in the security team?
We’re still a small team, we’re a team of 6.

What kind of audit do you perform?
We’ve contracted with agencies to perform VAPT every quarter. Moreover, we perform internal audits which include white/black box, red team exercise.

Can you share some stats about the bug bounty program?
At the beginning of every month, we publish all these details on Twitter, SLAs are also available on our policy page on Hackerone.

What kind of major changes occured in the program since 3 years?
Internal process is where we focused more initially.
It was important to work across the aisle of departments within the organization to get everyone on the same page and to make them understand about the security risks/threats. We wanted to ensure that both our employees and vendors are working within the framework of a policy we’ve laid out. Once we started getting everything in place, we changed the bounty structure and increased the scope.

We also ran a couple of promotions and rewarded researchers with bonuses which are important to attract top researchers and make them focus on your program. On that note, another important thing is shorter turnaround times - this was another area where we have done a lot of homework. Still, a lot of changes need to be done and we’re on it.

As far as I can see the program is not managed by Hackerone, any reason for that?
We use to be a managed program but then we decided to move to non-managed because of a couple of reasons:

• The number of reports we receive was quite manageable by our internal team.
• Since we have our own team, it’s easy for us to understand the reports/risks and plan on the mitigation steps.

How do you to rate the issues?
We see how many users will get affected, if it is a direct exploit, if there are any pre-requisites to exploit the issue, etc. Like, an SQLi is straight P1, an IDOR leaking users PIIs is P1, and so on and so forth.

We’ve defined our rating policy on our page on Hackerone as well as the bounty table.

How do you handle the bugs internally?
Proactively and effectively :)
From report to Triage, probably it takes less than 1 hour. If it’s a P1 we fix it within mins to an hour - it all depends on severity and workaround. We also use Jira for tracking bugs internally.

What kind of bugs do you receive the most?
I’ll be honest, the most we receive are NA’s.
Currently, the valid reports we receive have decreased drastically, so there is nothing like “most kind of bugs”. But on average what we received the most is like CSRF and XSS.

Any changes planned in the near future?
Yes, increase scope, increase rewards and a live event (should happen soon).

Do you have any advice for companies who run or want to run a bug bounty program?
For companies who already run or want to run a bug bounty program, here are few things which you should consider:

• Quick Response Time.
• “Fix your bugs”, researchers will lose interest if you’re not fixing your bugs.
• Bounty on Triage, this will really attract a lot of researchers, the reason being researcher has given you the report which means he has vested his time/efforts, don’t make them wait for months for their reward.
• Clear scope/policy + bounty table.
• Take regular feedback from hackers and retain your hackers, making sure they don’t lose out interest from your program.

Any words for hackers?
Thanks to all the hackers that have participated in the program to-date.
Our bug bounty program with HackerOne will continue to evolve as we strive to strengthen our relationship with the hacker community with every report.

Conclusion

After some hard years in the bug bounty industry, tables have turned, Zomato greatly improved their internal process to manage the reports. SLAs talk by themself, ATT:2hours/ATB:1day is kind of a dream for everyone who plays bug bounty, companies and hunters all included. They also changed their way to communicate with hackers, and hackers are thankful for that.

17 hours to triage, resolve, and reward! That’s how fast @Zomato’s program on @Hacker0x01 is.

I’d like to also give a shoutout to @EdOverflow. In that narrow timeframe, he managed to mentor me!

— Karim Rahal (@KarimPwnz) July 23, 2018

Remember that the more hackers like your program, the more they will work on it, meaning more bugs found -> enhanced security!