Controlling The Risks Of Vulnerable Application Libraries

During the past decade, developers have increasingly leaned on third-party components, such as open-source libraries, to dramatically lighten the load during coding. These components can help reduce time spent adding basic or universal features and functions so that developers can focus their work on the innovative code that will differentiate their applications from the crowd. Unfortunately, this valuable short cut adds another layer of risk to the development process.

"The cost of including a library has gone way down. Developers aren't stupid, so they're naturally going to say, 'I don't have to write that code, I'll just pay a library to do it,'" says Jeff Williams, CEO of Aspect Security and a key volunteer in the OWASP organization, who explains that the resultant risk is that developers are pulling in potentially insecure code and running it with the full privilege of the application. "I can't really underestimate the amount of risk we're talking about here. If there is vulnerability in the library, you've now exposed everything that that application is in control of."

And while these components are subject to the same kind of vulnerabilities any other internally produced code could experience, they often aren't put under the same security microscope that the rest of the application is examined by.

"If the developers didn't actually write the code, they feel they aren't responsible for its relative security," says Tim Erlin, director of IT security and risk strategy for Tripwire. "Developers need to design with the understanding they will be responsible for threat analysis of the entire application, not just the code they've written themselves."

It's the reason why using components with known vulnerabilities was added to the OWASP Top 10 for 2013, Williams says.

"What OWASP did is say we know you can't go find all those unknown vulnerabilities in all those libraries, but as a first step, for chrissake, please don't use libraries with known vulnerabilities," he says. "So if there's a CVE somewhere identified, if someone has found a vulnerability in a version of the library and there are a number of fixed versions you could be using, don't use the vulnerable one."

But that is exactly what developers continue to do. According to a study last year by Aspect, more than one in four common libraries used for Java, among a pool of 113 million libraries downloads, were used with known vulnerabilities.

"When we did the math, if you have 100 libraries in your app and there's a one in four chance you're going to be downloading one with a known vulnerability, the chances of you having at least one library with a known vulnerability is pretty darned high," he says.

His firm's stats and his suspicions were further supported by more research released this year by several firms. In January, White Source found that of among its new customers, 85 percent of applications loaded to its Open Source Lifecycle Management contained at least some out-of-date components in their code base. Another study by component life cycle management company Sonotype points to some of the root causes of the vulnerabilities. Among a sample size of 3500, 76 percent reported their organizations have no control over what components are being used in software development projects, and 65 percent don't have an inventory of components used in their projects.

The problem of insecure components hasn't cropped up due to lazy or out-of-touch developers, but instead from a fundamental supply-chain issue, Williams says. Many developers insert components early in the development process using a Project Object Model (POM), through Maven, a common build automation tool that has become almost a de facto standard in fetching open-source libraries for development.

"When developers write it the first time, they create their POM and choose the latest version of the library, but then it gets frozen in from there," he says. "It doesn't evolve from there, so as new versions of the library come out, the developers have no way of knowing that; there's no notification infrastructure that says you need to update."

According to Wayne Jackson, CEO of Sonatype, Maven was never fashioned with any kind of security concerns in mind. When Jason van Zyl created it more than a decade ago, he meant it to help with the delivery efficiency of software. But as the project has run away with legs of its own, as open-source projects are want to do, it has effectively thrown the application security side of library-based development into chaos. Van Zyl hoped to bring order back from the chaos when he founded Sonotype, says Jackson.

Jackson believes that not only do organizations need to work on ways to get updating automated, but also component approvals based on application security policy sets. At the moment, Jackson says that not all organizations even have a component approval process in place, but among that subset the processes rarely work due to a lack of strategic automation.

For example, he told one story of a bank that came to his firm and told him about an audit that found a number of ways developers were finding to circumvent its processes.

"In one case, this bank had a whitelist of approved components and said developers were so frustrated with how long it took to get things through the approvals process and the whitelist was so constraining that they started working around it," he says. "One of the ways they worked around it was to pull components in that they wanted to use and renamed them so the new name matched something in the whitelist."

Instead of mechanisms like whitelists, Jackson advocates for platforms that are based on policies, which would then govern component use.

"What we believe is the only workable approach is to let humans define policies around which approvals workflows would make decisions to integrate those policies into a set of tooling and then automate the enforcement of policy, thereby granting or not granting approval for a given component within the development process," Jackson says.

While the problem of insecure components and libraries does need to be addressed, Williams notes that organizations should remember to prioritize the issue against other application security problems.

"I want to be really clear that just getting all your libraries straight is one part of a balanced security breakfast," he says. "You could have all the most secure components in the world and still write an application that has the other nine OWASP top 10 problems. I don't want people to divert all of their application security resources to focus only on that problem just because it is a relatively easy one to solve."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.