How Bug Bounties Help You Shift Left

For many organizations, the days when security acted as a final “check-in” are disappearing faster than the guacamole at a Super Bowl party.

Nowadays, cloud, agile, DevOps, and CI/CD pipelines demand that security shift left and become a routine part of the software supply chain, or SDLC. No Breaking News here. 

But have you considered how your HackerOne Bounty program can help you shift security left?

This blog details the concept of a Bug Bounty Lifecycle (BBLC), first introduced to us by HackerOne customer Verizon Media in a webinar with Chris Holt, Senior Bug Bounty Operations Lead and a proud Paranoid. 

The Importance of Proactive Security

The increasingly valuable information stored in internet-accessible systems makes it essential to have a proactive defense system. Hacker-powered security is a proven, effective way to adopt such a proactive posture. When you put the world’s largest ethical hacking community on your side to find vulnerabilities before a breach happens, you and your users win. 

HackerOne recognizes that welcoming outside security help is a process, and so we offer several ways to get into hacker-powered security that run the gamut from VDPs, to hacker-powered pentests, private and invite-only bounty, all the way to public bounty programs.

Verizon Media, which earned the top spot in our Top 20 Bounty Program list, has been running their program since 2014. Five years, $4M+ in bounties paid, and more than 5K resolved reports later, Verizon Media has matured their program well beyond “bugs in, bugs out.”

In addition to running a bug bounty program and fixing vulnerabilities in their production systems, the BBLC approach ensures future systems will be better protected against threats. This model for continuous application security improvement maximizes bounty program value to the organization and reduces the risk of future breaches.

BBLC: Think about your bug bounty program in the context of your SDLC

As organizations begin a bounty program, they rightly focus on fine tuning the basic bugs in, bugs out process. When welcoming outside hackers into your security operations is still new, there is a lot to get right — things like effective communications with hackers, triage, reproducing reported vulnerabilities, severity classification, bounty amounts, resolution process, and more. HackerOne has multiple resources available to help, from guides to our expert professional services team.

With these basics mastered, you’ll be delivering the kind of response times that keep hackers coming back, and the security results that help you sleep at night. This is precisely the right time to advance your approach to a BBLC. This technique helps you use the same vulnerability reports to drive improvements in your software production process, or SDLC, to ensure future code is continuously more secure. 

The BBLC consists of the exact same steps as the SDLC, but in reverse order, from outside (Deploy) inwards, all the way to Requirements. With the BBLC, you leverage the learnings from your bounty program to regularly upgrade the proactive security measures in your SDLC. 

Most Bounty programs target live deployed code running in production applications, and so it’s there hackers will surface bug reports. A typical bug gives you a payload that executes in production, so after the development team comes up with a fix, you Deploy it. When operating in a bugs in, bugs out manner, this is where you’ll likely stop. 

With BBLC, though, we’re just getting started! With time, you are likely to see enough of a particular type of vulnerability to justify implementing a tool and adding it as a new Test case. An example from Verizon Media is XSSHunter, which screens code for potential cross site scripting weaknesses before that code goes live. Now we’re getting proactive! 

Each hop to the left in the BBLC requires increasing investment—both up-front investment to create the security protection at that phase of the SDLC, and ongoing investment in developer time to adjust the way they work. In the Build step, you can invest by baking in the use of a package or library with certain classes of features as they are built. Verizon Media’s Paranoids team shares the example of the OWASP AntiSamy library, an open source API that helps ensure HTML and CSS code from clients is safe. 

Design brings the BBLC out of the developer domain and into the architect and system engineering team. Here, the impact is broader, changing the way all systems are implemented. For example, there may be an opportunity to work with the Architecture team to design a new control, such as requiring whitelist validation for all input fields.

Finally, you can take the lessons learned from a class of vulnerability and write Requirements, policies, or standards to address it. Of course, this is the most global type of change, and so you want to be sure it is based on plenty of data and experience with the vulnerability type you want to protect against.

Where you are in your hacker-powered security journey will likely determine how far to the left you can push your BBLC. But keep these tips in mind and look for ways to move past bugs in, bugs out and leverage your bounty learnings to holistically secure your software supply chain.