One question that comes up over and over again when I’m doing a security talk is how much does it cost to run a bug bounty? The answer is, of course, like everything that varies depending on what you want. From the feedback I get, I think people are really asking how much does it cost to do an entry level bug bounty on a single mobile app or website.
To answer that question let’s look at $14,000 which equates to about $1000 a month in bounty payments to your loyal security researchers and $200 in processing fees. You can probably do it cheaper by not paying anything and just doing kudos type awards, but that’s probably not going to get you many exploits. They also provide tools to help you manage the incoming defects which can be overwhelming if you get deluged at with lots of reports of the same exploit, especially at the beginning of a bounty period. for pricing. The cheapest price To be clear that’s just the external costs that doesn’t include your internal team who is responding to the exploits and it also doesn’t include your developer’s costs to fix the defects.
With all the best intentions, if you don’t have a plan then starting a bug bounty is a waste of time and money. Someone should be assigned to manage the incoming defects and to triage the defects before they get passed off to the developers. And someone needs to be assigned to fix the defects. Don’t assume you can pull a developer from any old team to deal with the defects as they arise. It requires effort to keep up with your submissions.
One of the most important Best Practices when running a bug bounty is to be responsive. Contrary to what you might read in the press, there still aren’t a huge amount of new paid bug bounties. Anything new on BugCrowd or HackerOne will attract attention. The quickest way to kill that interest is to be unresponsive. If it starts to feel like researchers are sending their exploits to a black hole they will go elsewhere.
Get back to the researchers with a positive or negative response quickly. A negative response is usually when the submission is a duplicate that has already been reported by someone else or if the exploit isn’t something you that you consider to be an exploit. Be clear up front on when you’re going to pay and when you’re not going to pay, e.g. 3rd party libraries or APIs.
And speaking of duplicate submissions, make sure your developers are ready to fix any exploits and get the new version deployed as soon as you can. If you don’t update early and update often with fixes for any new exploits then researchers will get tired of your duplicate submissions response and once again will go elsewhere. Update your app often to keep interest alive. The exploits will get harder to find over time and your app will grow more secure.
Finally be honest and transparent. Don’t accept submissions before the bug bounty start date. Don’t ever use Bug Bounties as a way to keep security researchers quiet by handcuffing them using terms and conditions. There have been several public examples where companies have dangled large payments in front of researchers but insist that they don’t release the information. They then stall payment till the researcher gets bored and moves on. Eventually, the exploit information will be uncovered.
Bug Bounties are a great way to get lots of friendly eyes to look at your mobile app or website for relatively small amounts of money. Bug Bounty websites such as BugCrowd and HackerOne can provide you with the tools to manage your bug bounty. If you have a plan, respond quickly to your submissions, regularly update your app with security fixes and are honest and transparent about the payments then your app will quickly become more secure.
Information radiators are valuable Agile tools in building transparency from the project team…