Are You Really Ready For A Bug Bounty

Originally posted July 20th, 2015 on LinkedIn




  1. Code Review                                                 YES / NO

  2. Vulnerability Scan                                          YES / NO

  3. Security Audit (Pentest)                                  YES / NO



If you can say YES to all three you are ready.



Bug Bounty's by some are being treated as a cheap alternative to the more traditional forms of security practices that should be followed in a Secure Systems Development Life Cycle (S-SDLC).  A bug bounty is a device that compliments your S-SDLC and should not be used to replace traditional methods.



Launching a successful bug bounty without following a well implemented S-SDLC will cost you heavily. 



A bug bounty should be seen as giving you that extra percentage of coverage in security.  Times are changing where companies were happy with a score 70-80 out of 100 in their level of security assurance.  The cost of that additional 30-20 points far outweighed the benefit.  This is the case no more...




  • The average cost of a data breach has increased to $3.8m

  • New legislation / compliance rules are being constantly introduced and the level of accountability has increased dramatically

  • A breach will cost you a loss of business - Your customer has entrusted their personal information and their business to you.  Consumer loyalty is very fickle.  You think you are the only company out there offering a particular product / service ??



Having followed a well implemented S-SDLC a bug bounty is an excellent device to help you get closer to that elusive score of 100.



Before you launch a bug bounty here are some points to keep in mind.  Having participated in many programs these are my validated opinions.



1)  As simple as it may sound, announce your bug bounty program internally to the development teams and the various business units.  Tell them what you are trying to achieve and possible outcomes of running such a program.



Also, make a press release about it.  Companies are always having security audits or running vulnerability scanners.  Your customers expect this.  However, not everyone runs a bug bounty.  This is a great marketing opportunity to let everyone know how serious you are about the security of your customers data, and how you are embracing the security researcher community to help further your security level assurance.  Don't let this slip by, it can only have a  positive impact for your company.



2)  Establish your response team.  You may wish to have a larger team for the first month or so depending on the scale of your application/s as the initial submission count will be very high.  BugBountyHQ provides members of its Security Research Team (SRT) free for the first week of your program to help with validation should you wish assistance



3)  Establish the internal process of handling a validated bug submission.  You want any vulnerabilities reported, in the hands of the right development team as soon as possible so it can be resolved quickly.  This also brings up the point of disclosure.  BugBountyHQ unlike the other platforms asks that no issues be disclosed.  After all, you paid them for the vulnerability so you own it.  However, the researcher may request from you that they can disclose publicly. They may do so ONLY if approved by yourself.  You need to decide your own policy ahead of time about vulnerability disclosure.



4)  For every validated bug it is a signal that somewhere along the way the S-SDLC failed.  It is important to learn why.  Have a process in place to examine these S-SDLC failures.  Its going to happen and occurs even in the best S-SDLC's. Learning from these mistakes and trying to ensure they do not happen again will only make your internal security review procedures better and better.



5)  With all processes in place, the next important step is ensuring participation in your bug bounty program.  The simple answer to this is awards - I will say it once, do not treat bug hunters like the help.  If other bug bounties are paying better money, why would they spend any time looking at yours.  Offer a good minimum bounty.  At a minimum, I would suggest $50, but if you have followed your S-SDLC I would start at $250.  This will bring the vast majority of bug hunters to your program.



6)  So now you have set a good minimum, this does not mean set the ceiling limit at a low amount.  Award the bug appropriately based on your own priority classification. Examples of good P1 issues would be Remote Code Execution and SQL Injection. Remember the $3.8m mentioned earlier, these are the likely suspects.



Fixing one of these, potentially just saved your company $3.8m, so award the bug hunter reasonably and within your budget.  In my personal opinion issues like these should carry a minimum of $5,000, with an ideal amount of $10,000.  I understand that not everyone is a Google / Mircosoft /Facebook / Yahoo / PayPal, but I know for sure that no one wants to pay the $3.8m and loose consumer confidence in their brand.



Figure your priority classifications before launching.  BugBountyHQ assists with this.





7)  Be transparent with payments.  It breeds trust between you and the researcher. The BugBountyHQ platform actually insists on it and you cannot launch a program until you have given example minimum payments for various bug categories.





Viewed from a researcher perspective







8)  Now you have established a sizable pot of money aside for your bug bounty program.  You are ready to find or build your own platform.



You can choose to host your own bug bounty platform.  BugBountyHQ has created a platform for this specific purpose.  It is installed on your own network independently of BugBountyHQ, whereby you handle the entire program including payments.  There are a couple of benefits to this platform if independent is the route you wish to take.  The platform is already written for you, therefore no development costs.  All awards / points made on your platform are also reflected on BugBountHQ's global leader board and your bug bounty program is displayed and linked too, from the the BugBountyHQ platform ensuring immediate exposure.  You bug bounty will also benefit from the built in tools on BugBountyHQ to ensure you maintain a high level of participation.



Alternatively, you can select to have your program hosted on one of the bug bounty platforms such as BugBountyHQ, BugCrowd or HackerOne.  All offer similar services.  BugBountyHQ's fee however is 15% per bug as opposed to the 20% charged by the other platforms.  Why ?  Simply, we want to put more money in the hands of the researchers.  After all they did all the hard work.



9)  Now that you have decided upon BugBountyHQ being your preferred choice to deliver your bug bounty program.... :)  You need to lay out your own particular rules and scope of the program.  This is important to ensure the researchers look at what you want them to look at and do not report things you consider not to be of importance.  Unfortunately you will get some reports that are out of scope, this is likely that the researcher jumped in quickly to file some reports.



10)  Launch.  Within the first hour you will start to see issues filling up your inboxes.  This is where the work really starts.  As well as having access to BugBountyHQ's SRT free for your first week (if you so choose), BugBountyHQ's duplicity engine - Chameleon, helps to filter duplicates of the first reported issue even if it has not yet been triaged. You will also have issues that have fallen out of scope, Chameleon also assists with this.



Bugs processed by Chameleon, as good as it is, still requires a human to check and mark of duplicate items.  It does help grouping issues under the first reported issue for easy tracking allowing you to quickly close out these bugs emptying your open cases.



11)  Communication is important with your researchers.  In 99% of the programs I have participated in, it is asked that no vulnerability scanners are ran against the applications / networks and sending in the report output as a bug submission.  I completely agree with this, in fact all my own testing is completely manual.  But, on the flip side of the coin don't send the researcher back an automated response. They are spending time on your program.  Go that step further and make them feel part of a bigger team and write them a response.



12)  Keep the researcher updated as much as possible, when ever possible.  A very quick way to deal with this problem is once you have verified and triaged a bug to be fixed, pay the researcher there and then.  You will then only likely hear from them once a month when they do a spring clean of their own outstanding cases asking if the issue has been resolved.  Your going to pay them anyway. Doing it at this stage would be like pressing the noise cancellation button on a good set of headphone while sitting on an airplane.



13)  Depending on the scale of your application/s or size of your software products (Yes BugBountyHQ also provides for Software based bug bounties), you may find things slowing down at some point.  This could be for a number of reasons.




  • All the low hanging fruit (if any) has been picked through

  • The skill set of the researchers participating is lower than anticipated

  • New programs have launched and the "farmers" have moved on to newer pastures

  • New programs have launched offering bigger bounties

  • The perception that a program has been running for a while therefore the actual cost of the bug (time) becomes a lot higher to the researcher as it is likely it will take them longer to find one.  So it is easier for them to just move on to another newer program where their ROI will be higher



The fix is easy.  I have seen many programs start with a high minimum bug bounty and after only a few weeks you see that they have reduced the minimum by almost half (most likely they did not anticipate the amount of valid bug submissions they would receive).



This is completely back to front.  When the participation levels drop, this is a clear indicator that action needs to be taken.  Here are some things that you can do and things that BugBountyHQ already offers within its platform




  • Its your program, you can change the rules when you like.  Increase the minimum bounty and increase the amounts within your example reward matrix.  This helps to recognize the additional effort being required to find security vulnerabilities.

  • BugBountyHQ offers a Capture the Flag.  This can greatly increase participation.  Whilst trying to capture the flag the researchers will inevitably uncover more unique issues during the challenge






  • If you make any code changes to your application let the researchers know. They may have already looked at it previously and feel they have covered it off sufficiently already and will not be aware of any new changes.  BugBountyHQ provides you with a Program blog, a simple but very effective tool





14)   Congratulations, you are now running a successful bug bounty campaign. Each bug you fix is bringing you one more step to that 100/100.  Each fixed bug further protects your most valued assets.  In no particular order - 




  • Your customer

  • Your R&D

  • Your Brand

  • Your Shareholders

  • And in some cases your Job



I hope there has been some points worth considering.  I would just finish by saying - make the researcher feel like an extended part of your security team, your results will be far better.