Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

12/29/2016
08:00 AM
Jason Haddix
Jason Haddix
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

The Bug Bounty Model: 21 Years & Counting

A look back on the beginnings of crowdsourced vulnerability assessment and how its robust history is paving the way for the future.

When Netscape launched the first bug bounty program 21 years ago, it redefined the way companies approach system vulnerabilities. Today, there is widespread adoption of crowdsourced security programs across mainstream companies with more than 600 publicly disclosed programs and counting.

I’ve worked on a number of these bug bounty programs over the years, and served as director of penetration testing for HP Fortify. The changes have happened so fast, it’s easy to lose sight of how far we’ve come since the very first program was introduced in 1995. As we approach the new year, let’s take a look at the robust history that set the foundation for the modern bug bounty program.

The First Bug Bounty
Netscape Technical Support Engineer Jarrett Ridlonghafer designed and launched the first bug bounty program to discover vulnerabilities in Netscape’s beta version Navigator 2.0 Internet Browser. The company offered cash rewards to hackers who found bugs in the software.

Although this was a major advancement for the security industry, the model wouldn’t catch on for another seven years. By 2002, IDefense launched its own bug bounty program and in 2004, Mozilla created a program that is still running today. These early programs paved the way for the modern bug bounty and for the emergence of managed programs and bug bounties as a service.

Breaking the Mold
In 2010 and 2011, Google and Facebook took notice of crowdsourced security, adding them to their business models, which increased their popularity and incentivized more researchers to join the bug bounty community. In March 2011, Facebook paid a 22-year-old security researcher $15,000 for a bug discovered. By 2015, Facebook had paid more than $4.3 million to researchers globally.

Bug bounty programs were beginning to increase in popularity, yet many organizations still perceived them to be too risky. This perception was tied to the belief that a bug bounty gives hackers free reign of critical code. But the reality is much more controlled than that, because, whether you invite hackers in or not, as long as applications are connected to the Web, they’re vulnerable. Tapping into the intelligence of thousands of security researchers helps identify these vulnerabilities before the bad guys do and lowers the risk of being vulnerable.

Bug Bounties as a Service
In recent years, the growing need for bug bounty programs and the challenges and costs associated with managing them internally drove the creation of third-party platforms or bug bounties as a service. This opened new pathways for a growing hacker community and furthered adoption by other market sectors such as healthcare, financial services, automotive, and the Internet of Things.

For companies, third-party platforms offer the opportunity to create personalized programs by connecting organizations with trusted partners and a community of diverse security researchers. For researchers, the third-party platform verifies their results, handles arbitration issues with the company, and makes it easier for individuals to get paid and move onto testing for more bugs. Third-party platforms also drive the creation of a thriving community where researchers connect, educate, and inspire one another in an environment that allows people with a variety of backgrounds to share their knowledge and expertise.  

The Future
Crowdsourced vulnerability assessment has evolved to include more than just public programs. As I mentioned earlier, a common misconception about the bug bounty model is that all programs are public. In reality, the majority of all programs launched are invite-only. Private, ongoing, and on-demand programs are incredibly common and give companies a way to facilitate testing on harder-to-access applications, or focus testing on a small subset of an attack surface to meet organizational testing needs.

Private programs allow organizations of all sizes (like Western UnionOkta, and Aruba Networks) to validate the security work they’re doing internally, and leverage a curated crowd of talent to scale up their team and improve response time before going public.                  

Crowdsourced security programs have taken on many different forms and will continue to play a major role in securing applications, especially as companies face increased pressure to release updates and keep their customers’ data secure. From the increase of vulnerabilities in healthcare devices, IoT and the automotive industry, these programs can bring advancements to industries across the board. With the willingness and constant interest from intelligent engineers, bug bounty programs will continue to thrive.

Related content:

Jason is the head of trust and security at Bugcrowd. Jason works with clients and security researchers to create high value, sustainable, and impactful bug bounty programs. He also works with Bugcrowd to improve the security industry's relations with researchers. Jason's ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Joe Stanganelli
100%
0%
Joe Stanganelli,
User Rank: Ninja
12/31/2016 | 12:54:14 PM
bounty misconceptions
In addition to public vs. private-only, another potential "misconception" (if that is the right word in this case) that abounds among many researchers/hackers is that you get a payday just for discovering (1) *any* security bug and (2) anything that *looks* like a security bug.  Additionally, they operate under the misconception that (3) they will necessarily be believed.

I still remember the 2013 case of Khalil Shreateh, who -- after several repeated reporting attempts to Facebook on a serious bug -- wound up having to hack Mark Zuckerberg's Facebook account and post to his wall to prove the bug he had found.  Facebook then continued to deny Shreateh the bounty because he had technically violated Facebook's TOS in hacking Zuckerberg's account -- despite admitting that the company was too "hasty and dismissive" in not rewarding him earlier.

(In the end, Shreateh got an $11k payout from an IndieGogo fundraising campaign in lieu of a Facebook-awarded bounty.)
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
MITRE Releases 2019 List of Top 25 Software Weaknesses
Kelly Sheridan, Staff Editor, Dark Reading,  9/17/2019
7 Ways VPNs Can Turn from Ally to Threat
Curtis Franklin Jr., Senior Editor at Dark Reading,  9/21/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16695
PUBLISHED: 2019-09-22
phpIPAM 1.4 allows SQL injection via the app/admin/custom-fields/filter.php table parameter when action=add is used.
CVE-2019-16696
PUBLISHED: 2019-09-22
phpIPAM 1.4 allows SQL injection via the app/admin/custom-fields/edit.php table parameter when action=add is used.
CVE-2018-21018
PUBLISHED: 2019-09-22
Mastodon before 2.6.3 mishandles timeouts of incompletely established sessions.
CVE-2019-16692
PUBLISHED: 2019-09-22
phpIPAM 1.4 allows SQL injection via the app/admin/custom-fields/filter-result.php table parameter when action=add is used.
CVE-2019-16693
PUBLISHED: 2019-09-22
phpIPAM 1.4 allows SQL injection via the app/admin/custom-fields/order.php table parameter when action=add is used.