Bug bounty programs are a fantastic alternative to supporting your QA team in building better, more secure software.
August 1, 2013. Knight Capital Group opened its trading business. With more than 1,400 employees, Knight was the largest U.S. stock trader, with a market share of 17.3% on the NYSE and 16.9% on the NASDAQ. For any broker, working at a place like Knight Capital would be a dream.
But today was not like any other day. At 9:00 am, when the New York Stock Exchange opened to the public, the first retail investor of the day gave an instruction to interact with the market. Just 45 minutes later, Knight Capital's software had executed more than 4 million transactions, losing the company $460 million and leaving it on the brink of bankruptcy.
What happened? Like most catastrophes, it was an unfortunate chain of events that had to do with computer code. The day before, the development team released an update to their production environment. On the surface, nothing major, but the unintentional bug that was implanted was a ticking time bomb.
Bugs can range from mildly annoying to downright destructive. They are sometimes seen as a quirk of a piece of technology, in the same way that the JavaScript community has accepted that its rather byzantine approach to floats is part of its charm.
Other times, bugs can be devastating, affecting millions of users around the world. A case in point is the Log4j Disaster that left the tech community up in arms for weeks on end.
For those who don't know, Log4j is one of the most popular Java-based logging utilities on the market. An exploit was found that allowed third parties to remotely execute code on a targeted computer, allowing them to steal data or install malware.
How big was the problem? Akamai Technologies reported over 10 million attempts to exploit the bug per hour in the US alone, considering companies like Apple, Amazon, and Twitter rely on Log4j, you can start to get an idea of how sensitive this was.
But what is a bug?
A software error is an error or fault in computer software that causes it to produce an incorrect or unexpected result or to behave in an unintended manner. Contrary to popular belief, a bug is not necessarily caused by writing bad code (although we cannot disagree that this is one of the main causes).
Consider for example NASA's Climate Orbiter , the $125 million project that crashed and burned on the surface of Mars. The reason? A part of the software calculated the force the thrusters needed to exert in pounds of force. While another read the data assuming it was in the metric system.
In isolation, each piece of code was doing what it was intended to do. The problem was a miscommunication; engineering consultants at Lockheed Martin Astronautics in Colorado analyzed the numbers but forgot to convert them to the metric system. NASA, on the other hand, assumed the calculations were in newtons per square meter, as that was the standard.
Another example, the Knight Capital bug was due to some legacy code that was never removed from their systems, one of the flags that came with the update triggered the old code, and made the software that was in a testing environment, then try to process as many operations as possible.
In a review of events, the investigation found that Knight Capital did not have formal code reviews or a quality assurance department for that matter. In other words, no one was assigned to check for possible errors. They didn't have enough safeguards.
Unfortunately, QA departments, DevOps engineering, software testing, and code reviews are not enough to prevent bugs. At best, sometimes we can only catch bugs as they occur in production and try to fix them as quickly as possible.
The external perspective
Software is developed in a very specific environment, between having to meet user requirements, working to meet a deadline, aligning your workflow with other developers, and having to respond to last minute changes, bugs can go unnoticed.
As the saying goes, hindsight is 20/20, reviewing code after the fact is a very different beast than doing it under pressure. Every software developer has reviewed the code they made in the past and realized they could have done better. That's easy to say when it's not 4am and you have 10 hours before you go to production.
Users, on the other hand, interact with our products in a different environment. They can use it whenever they want, on their own platform. As such, it is not uncommon for users to encounter bugs.
For a user, bugs can range from quirky to downright frustrating, but what if there is a way for bugs to benefit users, the coding community, and ourselves?
Enter Bug Bounty Programs
A bug bounty program is an arrangement offered by many websites, organizations, and software developers by which individuals can receive recognition and compensation for reporting bugs, especially those related to security exploits.
Bug Bounty is extremely popular and is used by some of the biggest technology companies in the business, including Twitter and Google. Even the US government rewards individuals who report security vulnerabilities on their websites.
Dozens of aggregated sites maintain a list of active Bug Bounty programs, and entire communities have grown up around them. Why are they so popular?
Well, software development is one of those fields where a million minds are better than one. There is only so much testing a developer can do on their own. By asking the community for help, users and programmers can test edge cases for potential bugs and security exploits.
He encourages people with knowledge to help him protect his product rather than exploiting potential weaknesses. It's a democratic effort to build better, more secure software.
In fact, some young developers have managed to find positions at companies thanks to bug bounty programs. They were able to showcase their talent firsthand and prove that they understand programming, security practices, and software development culture.
For a company, setting up a bug bounty program is relatively easy. Again, there are dozens of sites listing open programs and it's just a matter of publishing your own project and also offering a reward that aligns with the size and scope of your business.
Suffice to say, bug bounty programs are not quality control or an alternative to something like DevSecOps, it's a program that exists alongside its own security measures. Its full potential can only be explored if we are already doing our best to create the best software possible.
