It’s no secret that more and more companies are jumping on the Bug Bounty Program band wagon, and for good reason, there is a lot of value to be had there. However, rolling out a Bug Bounty Program (BBP) before you have done your own due diligence can often cause more problems than it solves.
Bugcrowd, one of the largest bug bounty program service providers touts that within the first two weeks a typical company with a new BBP will see 5 critical vulnerabilities, 70 unique vulnerabilities and 200 total vulnerabilities. Those are impressive but potentially overwhelming stats. If you reverse the math a bit, that means that organizations need to:
- Triage 200 issues
- Throw out 130 false positives
- Rank, Reproduce, and Assign 70 issues
- Rank and address 5 critical issues and determine which need to get fixed first
I am not advocating for that it’s better not to know about these vulnerabilities, or against Bug Bounty Programs. It is critical that you know the threat landscape of your organization and software, and BPP’s are a valuable component of a mature program, but they should be rolled out to an organization of reasonable security maturity.
Bug Bounty Programs support software assessment tools and external security assessments. Tools are a great place to start. They find a lot of common vulnerabilities faster than humans but generate a lot of false positives and miss compound, business logic, and other vulnerabilities. Once you’ve fine-tuned your tools and have removed the “low hanging fruit” from your results, getting an external software assessment is a good next step. This external security assessment is expert driven and can go deeper than any tool. They’ll find issues that elude tools and give you context on how to effectively remediate and train your developers and testers to minimize the number of issues introduced into code in the future.
After automated and 3rd party penetration testing processes have been rolled out and optimized, has been conducted, a bug bounty program is a great piece to add.
There are more steps to a mature Application Security program including organizing your external and internal messaging, doing security training, creating an internal security and bug discovery program and feeding all of your information back into your Secure Development Lifecycle program. I’ll be diving into each of these in a future webcast, please tune in then.
Security Researchers will frequently uncover vulnerabilities in software even when they aren’t looking for them and even when there is no Bug Bounty Program enticing them with a reward. When a researcher finds an issue they’ll frequently still submit the issue to you without expectation of a reward if the submission process is easy to do.
It’s important to understand how to treat Security Researchers with respect. Ultimately, they want roughly four things:
- Respect: The Security Researcher is a professional giving you free testing. Their motivations may vary, but they’re not malicious. If they were, they wouldn’t be telling you about the issue they found.
- Rewards: Yes, they’d like to be compensated for their time through company SWAG, money, an interview or some other reward.
- Results: They are telling you about the issue because they want to see the security issues resolved. Set expectations with the researcher and follow up on a secure line of communication.
- Recognition: Security Research can be a reputation game. I can remember Ian Beer’s (https://en.wikipedia.org/wiki/Ian_Beer) name because he shows up in nearly every iOS and MacOS update I see. Rolling out a Bug Bounty Hall of Fame is a great way to encourage researchers.
External Messaging is the single most important thing you can start with, though. Making sure researchers know how to contact you, and your preferred terms of engagement can go a long way for your credibility when talking with a Security Researcher. Don’t make them jump through hoops to give you free testing. At the end of the day, if you make this easy, they’ll make it worth your while.
I’ll be diving into much more detail on creating a collaborative & social application security program at SOURCE Conference Seattle today. If you are unable to make the event, feel free to download my presentation slides here. If you have any questions or would like any additional information, please contact us at getsecure@securityinnovation.com.
