Big spike in chatter about #bugbounty programs over the last 48 hours. That’s a very good thing. I would like to share my thoughts on this topic from the experience I’ve had leading security at a company with ~500 software engineers.
First, thanks to folks like @k8em0 & @caseyjohnellis and companies like @Hacker0x01 & @Bugcrowd - #bugbounty programs can built and managed much easier than they could 5 years ago. But if you are someone who is in a position that can implement a program...
the first question you should ask is: Are we mature enough to do this? That question should not be taken lightly as we saw from the @Uber situation even they were not prepare for the types of situations you will have to deal with.
By maturity: Have you implemented a secure software development lifecycle that lends itself to having near-zero security flaws by the time the #bugbounty researchers take a crack at your code? If your answer is “No.” then spend you time & efforts improving other aspects first.
1 - Train your Engineers. Don’t just license some vanilla web-based training either. Everyone knows Engineers will click through as quickly as they can and guess at the 10 completion questions correctly. Use a tool like @codebashing & teach them how to hack.
3 - Embed security testing into the build pipeline. It should not be an after the release or side effort. Ever time a build performed, check for flaws in an automated, scalable way. But, my advice is to NOT blast the results back at engineering. False positives erode trust.
There will be plenty here and having folks to can triage each finding and only report what real to the teams is important.
4 - Run automated scanning before releases against the web UI in a repeatable way using credentials for every user role. Again, triage those results and feed them back to engineering in a way they can consume & take action (eg JIRA project integration).
5 - Run real threat model-based application penetration testing against your applications regularly. Utopia would be with every release, but may not be feasible for some (most?) orgs. Monthly or quarterly is a good benchmark. Triage findings...
and use this opportunity to reinforce training. Demonstrate findings in person or screen capture so when developers are looking to resolve the finding they can fully understand the problem - this is often a gap between security testers & engineers.
6 - To me, #bugbounty programs come at this stage. The value they bring is that they allow outside parties to focus on finding the very difficult to discover / high impact vulnerabilities that your program wasn’t able to discover. Don’t try to roll this on your own.
You need to think about if you are mature enough to handle the findings that come via this pipeline. In all the other aspects of your program the clock is ticking on your own time, in a #BugBounty program there are other who are not your employees involved & there is risk here.
You also need to think about a public or private program & where the researchers will target your environment. If you have production environments with PII & sensitive or regulated data, that might not be the best target. Perhaps a staging environment w/ fake data is best.
Botton Line: #BugBounty programs can be a fantastic addition to your security program. They are not a silver bullet nor should they be implemented without a level of maturity that can deal with the results - both the vulns & the interactions with participating researchers.
