Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

5/22/2013
11:54 AM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Controlling The Risks Of Vulnerable Application Libraries

Libraries are easier to use than ever, but they're piling on more risk to the development process

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. Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Commentary
What the FedEx Logo Taught Me About Cybersecurity
Matt Shea, Head of Federal @ MixMode,  6/4/2021
Edge-DRsplash-10-edge-articles
A View From Inside a Deception
Sara Peters, Senior Editor at Dark Reading,  6/2/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-23394
PUBLISHED: 2021-06-13
The package studio-42/elfinder before 2.1.58 are vulnerable to Remote Code Execution (RCE) via execution of PHP code in a .phar file. NOTE: This only applies if the server parses .phar files as PHP.
CVE-2021-34682
PUBLISHED: 2021-06-12
Receita Federal IRPF 2021 1.7 allows a man-in-the-middle attack against the update feature.
CVE-2021-31811
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an OutOfMemory-Exception while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-31812
PUBLISHED: 2021-06-12
In Apache PDFBox, a carefully crafted PDF file can trigger an infinite loop while loading the file. This issue affects Apache PDFBox version 2.0.23 and prior 2.0.x versions.
CVE-2021-32552
PUBLISHED: 2021-06-12
It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-16 package apport hooks, it could expose private data to other local users.