Third-Party Software Library and Airbag Grenades

Recently Contrast Security ran some analysis of our customers’ 3rd party software usage, which is a huge security blind spot for most organizations, and our data tells an interesting story. I’m going to tell you why 3rd party libraries are a serious security problem, and why you can’t solve it without sensors.

Most people understand there’s a risk with using these 3rd party components, but there’s very little supply chain management for them. How do you know there are no vulnerabilities in them? What if someone finds one later? Let’s look at a situation that just occurred in the real world to see just how far down the river we left our paddles.

In case you didn’t know, many parts in your car are not actually made by the manufacturer. In fact, some of those parts are sold to many different manufacturers. For instance, Takata is a company that makes airbags, seat belts, and other safety equipment. Their parts are used in BMWs, Hondas, Nissans, Toyotas -- you name it. Well, they set out to make an airbag, but they accidentally made a grenade: 

"At the heart of the problem is the airbag’s inflator, a metal cartridge loaded with propellant wafers, which in some cases has ignited with explosive force. If the inflator housing ruptures in a crash, metal shards from the airbag can be sprayed throughout the passenger cabin—a potentially disastrous outcome from a supposedly life-saving device."

Well, okay. That’s bad. Like Heartbleed, but more literal. In this case, the automotive supply chain is controlled so well that when it’s revealed that an airbag is faulty, it can be traced from its possession from Takata all the way through the various manufacturers, distributors, dealerships, and all the way to you, the car owner. You get a letter in the mail that says, “Hey, bring your car in. We’d hate to kill you and stop receiving your lease payments.”

No One is Going to Tell You You’re Vulnerable

A technology executive could be forgiven for thinking their developers would somehow find out if their 3rd party libraries had the software equivalents of exploding airbags in them. Unfortunately, that just doesn’t happen a lot. Here’s why:

• The vulnerabilities are invisible. Developers can’t see the library as being vulnerable when looking at them because it’s not obvious when something is vulnerable. Somebody has to find the vulnerability first. Even if a vulnerability is found, the message about its insecurity gets lost along the way for the next two reasons.

• Reason #1: There’s no standard channel to send security announcements. Sometimes the announcement of a vulnerability goes out as part of a release note for a new version. Sometimes people just drop some zero-day on the Full Disclosure mailing list. Sometimes there’s a security@ email address that you have to subscribe to ahead of time to receive announcements. Sometimes, well, a CVE just pops out of nowhere and there’s no record of it from the vendor at all.

• Reason #2: There’s no standard data format for these announcements, anyway. Because of this, there’s no way to catalog and query them. It would be great if CVEs were structured in a way that allows anyone to ask if a particular library has a vulnerability. That would’ve made building a library analysis feature into Contrast Assess much easier!

A big application can employ hundreds of libraries. We found Contrast Assess customers to be using an average of 71 libraries, with the vast majority coming from the open source world. What are the chances the typical organization is absorbing this decentralized, ad-hoc data about library insecurity efficiently?

If you guessed zero, you’ve reached at least my level of security cynicism, and my evidence says we’re both right -- 58% of applications monitored by Contrast have at least one vulnerable library. Many have multiple. When you have at least one vulnerable library, chances are you actually have three or more vulnerabilities -- probably because many libraries are repeat offenders.

Vulnerable or Not Vulnerable: This is Not the Only Question

Contrast Assess has you covered -- you know which of your libraries are safe, and which have known vulnerabilities. Some other tools are starting to do this too, like the open source OWASP Dependency Check. Knowing that a library has a vulnerability is a big piece of the puzzle, but there’s an important second piece: Are you actually using this library?

We’ve found 78% of libraries are never actually used by their applications. On average, people only use 7.7% of the code in their libraries. So, although these libraries are the biggest piece of our code artifacts, they’re not that big a piece of our attack perimeter. Accordingly, most of the time, the sky is not falling because of a vulnerable library. Asking the developers to upgrade their libraries to a newer version when they might not need to is exactly the type of relationship-straining behavior to avoid. 

Let’s look at how to use sensors to avoid unnecessary and possibly difficult work of removing or upgrading a library. An old version of the Atlassian Stash application has a library with three known vulnerabilities. We can see this pretty clearly in the Contrast Enterprise Libraries page:

The data the Contrast agent collects gives our customers the ability to make a smarter risk decision. Yes, the library has vulnerabilities -- but users can see that their app doesn’t actually use any of the code classes from this Java library:

This means that it presents no harm, and the vulnerability can be “lived with” for now, or stripped from the build without risk of depriving the runtime of a critical component. There’s a chance that you will use the vulnerable code in that library in the future since it’s available, so work with the developers to include upgrading in their long-term plans. 

This is the magic (and the beauty) of Contrast -- it provides the type of context from inside the application like no one else. That context leads to much leaner, more accurate, and more actionable analytics -- which is the only way application security scales.

Developing and maintaining a robust application security program does not need to be a daunting task.

Perhaps, all it takes is rethinking your existing program and moving to one that leverages a continuous application security (CAS) approach. 

Organizations practicing CAS quickly determine how a new risk affects them, design a defense strategy, and measure their progress to 100% coverage. By implementing eight functions within an enterprise you can assemble an effective application security program.