Don’t Panic: Insecure Libraries Are Not the Apocalypse

The use of open source software has more than doubled from 6 billion to 13 billion component downloads per year. It’s almost impossible to imagine an application that doesn’t leverage a significant amount of open source code somewhere in the stack. This is great news for productivity and progress, but there is also clear evidence that hackers are starting to focus on the software supply chain. 

After two years, many organizations have taken notice of this important problem:

• OWASP added A9 “Use of Components with Known Vulnerabilities” to the OWASP Top Ten.
• PCI 3.0 now requires the use of secure components.
• FS-ISAC issued a new standard governing open source component use.
• MITRE CWE-937 was added to focus on components with known vulnerabilities.

Despite all this activity, securing components is just one part of an overall application security program. Just because it’s easy to understand and relatively easy to tackle, doesn’t mean that’s where you should put all of your effort. Let’s start with a few facts to make sure we’re all on the same page.

1. The Vast Majority of Component Code Is Unused

While it is true that 80 or 90% of the code in many applications comes from components, that’s not the end of the analysis. First of all, many insecure libraries are “dead dependencies” that are required to support a feature in another library that your application doesn’t use. In this case, even if the library is riddled with security vulnerabilities, it makes no difference because that code isn’t used.

Second, for components that aren’t dead dependencies, only a tiny fraction is typically used – less than 10% of the code in a typical library is actually executed. Often only a single class is actually loaded. Think of it this way – your custom code has roots that extend down into a mountain of components. But those roots only ever touch a tiny percentage of the mountain. So any vulnerability in the component that your application’s roots don’t hit is unexploitable and irrelevant. 

2. Known Vulnerabilities Are Only a Small Part of the Component Security Problem

Components with “known vulnerabilities” have flaws that were discovered by security researchers and published in a vulnerability repository like CVE, Secunia, or OSVDB. Some of these flaws are serious, and others much less so. In general, the easiest thing to do is to update these libraries to a version that isn’t vulnerable. You can use Contrast or tools like OWASP Dependency Check to find out if your application is using libraries with known vulnerabilities.

Components also have numerous “hazards.” These are dangerous methods that perform important tasks. Your components might have methods that delete files, execute system commands, destroy databases, and the like. There is nothing inherently vulnerable about these methods, but they’re not well documented, and developers often make the mistake of passing in untrusted data or otherwise using these methods unsafely. Tools that only analyze source code cannot see these hazards, because even though the problem is in that source code, the hazard itself is buried inside a component. Only solutions that can do “whole application” security analysis can find these problems.

Finally, all components are very likely to have “unknown” or “latent” vulnerabilities. These flaws have not yet been discovered by security researchers.  At least, not the good researchers that actually publish their findings. There’s not much that you can do about these latent flaws, except to have a system in place so that when one is discovered, you can react very quickly to identify and update the affected applications.

3. Your Custom Code Is Far More Likely to Lead to Vulnerabilities than Your Components

Web applications and web services average a stunning 22.4 serious vulnerabilities in their custom code. On the other hand, the majority of applications don’t have serious vulnerabilities that stem from using insecure components. That’s not to say that using insecure components isn’t a problem. If you’re using a vulnerable version of Struts or Spring that allows remote code execution, that’s serious. But most applications *do* have critical vulnerabilities that stem from good old-fashioned insecure programming. There’s a reason that insecure components is only one of the OWASP Top Ten. 

Stay Calm and Focus on What’s Important 

You absolutely should make component security a part of your application security strategy. You’ll want to integrate some sensors somewhere in your develop, integrate, test, deploy process. This is basic patch management stuff. You’ll also want to be able to respond quickly in case another HeartBleed type vulnerability is discovered. So think about how you will be able to find out which projects are using what components. Hint: you’re going to want to have an automatically generated bill of materials available and searchable for every application.

Also, for more on the topic of known and unknown vulnerabilities in libraries, see my three part blog on Libraries and Application Securities, beginning with part one.

image credit: johanl