Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
Happy Thanksgiving everyone! After a hectic year, I hope everyone has some downtime to spend with their families. Again, I appreciate all the support. If any of you have some leftover professional development budget, please consider spending it on a paid subscription! It helps keep this blog going.
LET’S BE FRANK
Recently, there’s been a lot of talk about bug bounty, especially given the verdict around the Joe Sullivan and Uber case. In my opinion, bug bounty is one of those programs where the tail end of issues defines the value, but on a regular basis, it is just a pain to manage. Honestly, I don’t think I’ve spoken to one security professional that likes bug bounty, but everyone believes they should suck it up and do it.
Why is this? Why does managing bug bounty have to be so painful? I’ll talk about why the current state of bug bounty is so dire, and why we need to fix it now. I will also discuss how companies should think about bug bounty from a business objectives perspective.
The rise of the bug bounty
Honestly, bug bounties are nothing new. I’m not going to insult any readers by describing what a bug bounty is, but recently, there’s been a rise in formalized platforms. Before these platforms, many sites had informal security vulnerability disclosure programs (and still do). White hat hackers would submit security issues and way to reproduce them. Many times, people would do it to help improve an application or website they enjoyed. There was no expectation of payment. Many researchers actually did it in their free time and thought it was an important duty as someone in the security community.
Keep reading with a 7-day free trial
Subscribe to Frankly Speaking to keep reading this post and get 7 days of free access to the full post archives.