AppSec Mistake No. 2: Ignoring Open Source Library Use

We’ve been in the application security business for more than 10 years, and we’ve learned a lot in that time about what works, and what doesn’t. This is the second in a blog series that takes a look at some of the most common mistakes we see that lead to failed AppSec initiatives. Use our experience to make sure you avoid these mistakes and set yourself up for application security success.

Open Source Library Use Is Prevalent

Bottom line: If you are only worried about the security of your first-party code, you are overlooking a substantial source of risk. Developers are increasingly taking advantage of open source libraries to add functionality to code without having to re-invent the wheel. And that makes a lot of sense. We liken it to cooking a meal. If you’re preparing chicken parmesan for dinner, it’s unlikely you made all the ingredients from scratch. Instead, you probably bought the cheese, chicken, and sauce and combined all the ingredients to create your meal. Even if you made the sauce yourself, you likely used tomatoes and spices grown and prepared by someone else. This is also how software composition works. It doesn’t make sense to create the entire application from scratch when high-quality, functioning code that meets your needs already exists. In fact, some estimate that up to 90 percent of applications are now made up of third-party components.

And this new model comes with tremendous benefits – both for developers, and for the business – allowing both to move and innovate with unprecedented speed. Ultimately, with everyone creating code this way, it has become a necessary practice in order to remain competitive.

Open Source Library Use Introduces Risk

But there’s a flip side to all these benefits: reusable code means reusable vulnerabilities. When everyone is re-using code, a breach in one piece of open source code has far-reaching implications. And the bad guys know that attacking open source code gives them the most bang for their buck – one breach, millions affected. In addition, with the pace of open source libraries being generated, vulnerabilities are also being generated faster than anyone can keep track of.

To explain, we can take our cooking analogy one step further. Imagine if you prepared your savory meal only to discover there was a listeria outbreak in tomato crops. Can you be sure you didn’t use any affected tomatoes in your sauce? Are you willing to take the risk if you can’t be sure? Without knowing exactly where your ingredients came from, it’s hard to make an informed decision about the risk and take appropriate action.

With this complexity, it’s not surprising that most open source components remain unpatched once they’re built into software. In fact, this year, we found that 88 percent of Java applications had at least one flaw in a component.

This isn’t just theoretical risk either. In March 2017, a number of high-profile targets got zapped by what we dubbed the “Struts-Shock” flaw. This critical vulnerability in the Apache Struts 2 library enables remote code execution (RCE) attacks using command injection, for which as many as 35 million sites were vulnerable. All it takes is a well-crafted web request to trigger the vulnerable code.

Getting a handle on open source component use starts with visibility. When a big vulnerability in an open source component is announced, you’ll never patch in time if you have no idea where you are using the vulnerable component. Software composition analysis technologies help you create an inventory of which components and which versions you are using where – making keeping up with the bad guys much easier.

Learn From Others’ Mistakes

Don’t repeat the mistakes of the past; learn from other organizations and avoid the most common AppSec pitfalls. Today’s tip: Don’t ignore the security risks of open source libraries. Get details on all six of the most popular mistakes in our eBook, AppSec: What Not to Do.