Bug bounties are legal! Twenty-one years ago, Netscape launched the world’s very first bug bounty program. 'Netscape Bugs Bounty' was launched on the beta versions of Netscape Navigator 2.0 software, and awarded cash prizes and SWAG, depending on bug severity. (Sounds pretty familiar, eh?)
The program set the foundation for the bug bounty model–without their even knowing it–and we were curious about that day 21 years ago. We had the opportunity to get straight to the source in a Q&A with Jeff Treuhaft, who was one of the key people behind the Netscape bug bounty program as Netscape’s Product Director. Read on to learn more about why Netscape launched a bug bounty program, what came of it, and where Jeff thinks the model is going.
Netscape really pioneered how the Internet was built, as well as how it was perceived and accepted by users. How was security factored into that plan? As the man behind the product, how did you think about product security?
The internet was still so new back then (early 1994)–university research papers, early SMTP mail systems between universities and handful of custom-built IT network applications. The network and the "internet" then really didn't have security as we know today. We knew from day 1 that the commercial "web" was going to need security. And likely not just one mode of security. For most of 1994 and early 1995 the mainstream press was printing statements like the "internet will never be secure" and such. So initially we focused on securing the network link between the browser and the server using SSL (now known as TLS). This was very successful and continues to be the primary way all web traffic is secured more than 20 years later!
When Navigator was released in beta, it was unusual, but lent itself to the democratic, fast, and openness of what people liked about the Internet. What prompted Netscape to do that?
We released all versions of the browser as beta starting with the .9 version. At the time we wanted to get the features of the commercial browser in as many hands as possible as quickly as possible. Without the key features like security, we could not have been able to get so many site operators to open up "shop" on the web. Maximizing the number of commercially oriented browsers across the network was key to getting enough servers established to make the modern/commercial web the vibrant place that it is. We knew it was only a matter of time before others tried to build their own browsers with commercial features. As a young, upstart company we endeavored to maintain a fast, open approach to quickly developing a web-centric computing model. That resonated with a ton of people.
Along with releasing beta versions, you launched the first ever ‘Bugs Bounty’ (love that plural) program. How was that program perceived internally and externally?
In the wake of Navigator 1.1 and in the lead up to Navigator 2.0, we experienced an unusually high volume of reports of people finding security bugs in Netscape's browser. Netscape had already become notable via building our brand through fantastic PR and the IPO in August of 1995. This led more and more people to us, and more and more engineers trying and hack the products. Most of those reporting bugs in the early days were doing so out of curiosity or their own interest in finding out how 'secure' the product really was. At the time there were few if any real "standards" for how to securely implement network software systems. As the number of hackers grew so did the number of reports of security bugs in Netscape software. Pretty quickly the press latched onto these stories and soon we were spending a ton of time researching each report and confirming whether there really was a bug or (in many cases) it was not a confirmed bug.
This went back and forth over the course of many weeks until we reached a point where it was not really sustainable to continue to develop the software AND manage the random inflow of potential bug reports. The technical support team bore the brunt of the inbound security bug reports at the time and Jarrett Ridlinghafer came up with the original bounty concept and our VP of Marketing Mike Homer immediately understood the value of using the such a program to both make the product more secure AND solve the PR issues burning brightly at the time.
What kind of results did it get? Were they more or less than expected?
We weren't too focused on the actual bug metrics of the program initially, as I recall. We knew it was always better to have a community testing and hacking the product vs. just ourselves and our own QA resources. So any amount of increase from the 'Bugs Bounty' was upside. It was a really great PR win for the company at the time. We quickly turned negative stories in the press of how hackers were finding security bugs in our software to a positive story about how we were harnessing the growing power of the 'net' to make the product more secure.
We announced the first set of winners after 60 days and everyone involved 'won.' The technical community embraced the concept with lots of discussion in forums, debates, and original submissions. Hackers won, as several received $1000 cash and many others received Netscape SWAG and bragging rights. Netscape was able to create a more secure product and in the end, users and commercial customers had confidence that Netscape's products were more secure than anyone else's based on the sheer volume of sponsored hacking that was being targeted.
What was the hacker community like back then compared to now?
The intent is likely the same, for the most part, but the community is much much larger. The number of CS grads and self taught engineers back then were still quite small relative to today. And there were few if any courses in CS programs focusing on how security in software architectures should work. So while the intent and focus of the hackers is the same the sheer size of the community, its education level on these topics and its access to tools are all much more advanced. With the growing use of online repositories like Atlassian and Github you also have a concentration of where code is being cataloged and maintained. This helps bring the focus of the interested community into a common place which likely makes the bug finding more efficient overall, at least for more popular applications and code bases.
Looking at how far the bug bounties have come in the past several years, what has changed? What has stayed the same?
Well, I'd say the rise of 'Bugs as a Service' (BaaS) platforms like Bugcrowd show that the industry has really grown up expecting bug programs to be an essential part of every meaningful software development project. The same basic principles are in place from that first program, but the range of tactics and scope of testing continues to expand. I am sure there are ways now for smart engineers to even make a living hacking bugs–if they are good at it.
Twenty-one years ago did you ever imagine that bug bounties would be where they are today?
What do you think is the key to success for bug bounties?
The willingness of smart engineers to invest their own time to find the bugs. That innate curiosity or the compelled responsibility many of them feel is essential to have the community of contributors large enough to support all the software and system development we have today. Without their consistent interest and the investment of their time, no amount of cash reward would make programs like these ultimately successful.
In the past twenty-one years, the model created by Netscape has certainly evolved as more organizations have adopted the model and third-party organizations (such as ourselves) have brought the model to the masses. Additionally, with the introduction of private programs, bug bounty programs have certainly taken off. Want to learn more about this evolution? Tune in to our upcoming webinar with one of our customers, David Baker of Okta, on the current state of vulnerability discovery and bug bounties: