Implementing Bug Bounty Programs: The Right and Wrong Approaches

bug bounty security program

Threatpost catches up with David Baker, the chief security officer at Bugcrowd, about the future of bug bounty programs.

While bug-bounty programs may seem like a cure-all solution for companies looking discover vulnerabilities in their systems more efficiently, the fact remains that a program could overwhelm a firm’s internal security team and cause other major headaches if implemented the wrong way.

“You have to realize that the crowd is going to find a lot more vulnerabilities than your typical in-house pen-test team. So oftentimes, there’s this engineering push back, like hold on, we don’t have our internal processes set up,” David Baker, chief security officer at Bugcrowd told Threatpost.

Threatpost caught up with Baker to discuss the right — and wrong — approaches for  implementing a bounty program that can boost companies’ security effectively with minimal operational disruption. Listen to the full podcast below.

Click here for direct download of the podcast. For a lightly-edited transcript of the podcast, see below.

Lindsey O’Donnell: This is Lindsey O’Donnell with the Threatpost podcast. And I’m here with David Baker, the chief security officer at Bugcrowd and the VP of operations at Bugcrowd. David, thanks so much for joining us.

David Baker: Thanks for having me.

LO: So since we haven’t talked before, can you give us a brief introduction of yourself and how long you’ve been at Bugcrowd for?

DB: Excellent. So I’ve been at Bugcrowd for two and a half years. I was previously the chief security officer with Okta…before that, security architect at WebEx. I [also] ran all of the professional services at IOActive, which is a security research firm in Seattle. So I’ve been around security for about 15 years.

LO: So you’ve really seen it all then. I wanted to talk a bit about some of the top trends that you’re seeing in the bug-bounty landscape at this point. Is there anything that’s really sticking out to you in terms of how programs are evolving or how bounty hunters are changing?

DB: Yeah, about five years ago was, I think, the [era of the] web application, and so your web platform was sort of the mainstay for how researchers interacted. A lot of companies had a platform, a web application platform, that was accessible via the internet. And so researchers would typically interact that way, to find bugs and report them. What we’re seeing now is, a lot of the companies are moving towards more of an API-based platform, where you have a web application that sits on your cell phone, and that has an API layer that feeds back into a back-end service. And that’s pushing things to be more mobile, [and] it’s a much different target, particularly the API fabric.

And the other aspect is, they’re always trying to bring in a device, so with your mobile phone, there’s probably a device that sits on your wireless network in your house or office or something. So the combination of your API layer, some sort of IoT device being involved, this is actually becoming more and more prevalent. So what that’s doing is changing the nature of how your researchers are interacting with something that’s internet-available, but isn’t a web front-end. So it’s a much different style of attack, it’s a much different style of test, and so on and so forth. Devices are typically commoditized, you can pick them up anywhere, researchers have them, are able to get them very easily. And so they’re interacting at a hardware level sometimes. So we see the ability now to expand to new frontiers, with new complexities. We are actually trying to raise awareness and train researchers to start competing in that area as well.

LO: Yeah, I’m curious, you mentioned IoT. Obviously, that’s a huge threat when it comes to security. What kind of interest level are you seeing with IoT devices? And how is that different in terms of researchers and bounty hunters looking at those types of devices, because obviously, you have hardware and operating systems and different levels of that.

DB: Yeah, it’s interesting, because you had what I would call Gen One of your IoT device. And that Gen One would be your routers, or your switches that you typically have in your office. And nowadays, you have Gen Two (maybe even a generation three) which is your Ring devices, or…Xfinity as a cable provider, they have these devices that plug into your wall, and they help you sort of control the wireless signal in your house. You know, the Alexa devices, so on and so forth. So these interactive devices are very new, they sit in the household. Your watches, your Fitbits, so on and so forth, your drones, all of these are sort of these Gen Two devices that are pretty ubiquitous now. And those are going to be much different than your first gen where it’s pretty easy to tap in, you can actually get access to the firmware pretty easily. Nowadays, the Gen Two devices are much, much more commoditized hardware, but gaining access and the actual target is much different. And it also introduces the security awareness around supply-side security threats. So there’s a lot of interest in around having researchers identify potential areas of supply-side security issues.

LO: So can you talk a little bit about bug-bounty programs in general from a vendor’s perspective, and some of the challenges that vendors are facing when they launch a bounty program?

DB: Sure, yeah. From an operational perspective, that’s my team that handles the actual operations. So as a vendor, we manage the bug-bounty program for our customers — so [that includes] all the complexities of how to pair researchers (what researchers to bring in), how many researchers, and so on and so forth. I think oftentimes the initial challenge we see is that…the security team goes out and purchases a solution, but you have to realize that the crowd is going to find a lot more vulnerabilities than your typical in-house pen-test team. So oftentimes, there’s this engineering push back, like hold on, we don’t have our internal processes set up. There is oftentimes confusion with marketing people about “do we want to talk about it.” To talk about it is actually very beneficial, and it also attracts a lot of researchers, because they want to participate. So sometimes we see that the companies may not necessarily be ready to go right away. It’s part of the management piece; we help them get up and running. I think that companies want to start very slowly, they want to dip their toe in the water. And sometimes that can have a detrimental effect to recruiting researchers. When you go into a bounty program, you want to be ready, and to be ready means that you want to attract researchers, you want them to participate. And it’s hard to hard to do that with two or three researchers for a long time.

LO: Yeah, that’s a really good point. And then what so what, on the heels of that? What would be the very first one or two steps that a company could do to prepare themselves to launch a bug-bounty program?

DB: That’s a great question. You gotta have a good [service level agreement] (SLA) with your security in engineering. So have that SLA established, and if there is a really critical bug identified, how long [does] engineering [have to] fix it? Typically, that’s 24 hours, but[is it] fine if it’s a week? You have to have that [time period] established. And also-..if it’s a much more lower-impact bug, you don’t want to ignore those. You need to be able to have a commitment that engineering can fix those lower-level flaws in a month or six months, right, and have that process laid out. Because what’s going to happen is, when you have the money initialized, you will have these bugs come in and engineering will have to spend time on them, so they have to be part of the conversation.

We have the ability to integrate with the engineering life-cycle around how they’re doing software and security development. So you want them to be at the table when this happens; they need to be part of the process. And the next thing is, you really want to understand what your value target is, right? It’s not about saving money, it’s about identifying vulnerabilities. You will naturally save money by having those vulnerabilities identified. And, you can reduce your risk — that’s your ultimate cost savings. But you want to be able to have the capital in the beginning to make sure that researchers are coming to the table. Those are the two things that are really important.

LO: Do you think companies are aware of those at this point? Or do you guys really need to kind of hold their hands to help them understand that? How do you think the perception of bug-bounty programs is at this point?

DB:It’s a good question. It is getting there. So I think, you know, the past five years, it was really just more about really early adopters expanding their programs, and those early adopters have made a name for the bug bounties. Not everyone was coming in and saying, I want to do this. Early on, there was a crowd fear. The early adopters got around this fear of the crowd. Now that’s going away. So now, more companies are wanting to do this. But the idea here is well, I want to just try it, and spend a very little amount of money just to try it out. And while you can start at a lower-cost tier, you really have to have your processes [and] your engineering on board. That’s sort of the next phase for people, not just jumping in.

LO: Another question I had is, where do you see the future landscape going? When it comes to the operations behind the bug-bounty programs or when it comes to even the concept of vulnerability disclosure and how that plays into it?

DB:  It’s, it’s good question…Oftentimes, it’s very specialized. But what we’re seeing is that you’re really able to approach this as more of a Gig economy solution; we have companies that have very, very specific needs. And so while the bug-bounty program is going to be just a natural layer of your security fabric, or part of the onion, a few layers of the onion, companies will be able to leverage these crowd-sourced platforms to be able to do really targeted Gig-economy programs [for] a very specific problem, and having a very specific type of talent for that problem. Connecting them one-to-one that is where this next evolution is happening.

LO: It should be interesting to see how that plays out in the future. Well, David, thank you so much for joining us today on the Threatpost podcast.

DB: Thank you Lindsey.

Don’t miss our free live Threatpost webinar, “Streamlining Patch Management,” on Wed., July 24, at 2:00 p.m. EDT. Please join Threatpost editor Tom Spring and a panel of patch experts as they discuss the latest trends in Patch Management, how to find the right solution for your business and what the biggest challenges are when it comes to deploying a program. Register and Learn More

Suggested articles

The State of Secrets Sprawl – Podcast

In this podcast, we dive into the 2022 edition of the State of Secrets Sprawl report with Mackenzie Jackson, developer advocate at GitGuardian. We talk issues that corporations face with public leaks from groups like Lapsus and more, as well as ways for developers to keep their code safe.