The Hidden Dangers of Component Vulnerabilities
Dangerous flaws in open source components and dependencies lurk within most applications today.
April 21, 2017
It's been four years since OWASP first put third-party vulnerability risks squarely on the appsec map when it included the problem in its Top 10 list. But in that time, the risk has only grown as increasingly more applications today depend heavily on open-source libraries, frameworks, and other components, all with their own vulnerabilities.
It's a very large attack surface for applications today and one which has increased chances of security headaches. Here are some of the latest stats on this hidden problem.
Today's development practices continue to evolve toward the fast iterations of smaller builds. Developers are using approaches like microservices to chunk out monolithic applications into a sum of more rational and reusable mix-and-match elements.
In many instances those elements are open-source components. According to a study out this week from Black Duck that examined data from more than 1,000 enterprise applications, 96% of applications scanned contained open-source components. Not only are they present in most software today, but they make up a large percentage of that software's code base. According to some estimates, 80% of the average application today is made up of these components.
While these components have gone a long way toward helping organizations speed up software delivery processes and scale development, there's a huge risk that's piggybacking on these opportunities. That's because the majority of the applications that do use components include at least a few with vulnerabilities--many of which are high-severity.
Black Duck found that 67% of applications using open-source components contained known vulnerabilities in said components. On average, these applications had 27 of these component vulnerabilities, with over half of them being high-severity. These numbers can be even higher in certain types of applications. For example, one study by Veracode found that 97% of Java applications contain at least one known component vulnerability.
All of these exposures are adding up to increased risks to enterprises today. According to IT professionals surveyed by Sonatype, the number of breaches that can be blamed on flaws in open-source dependencies is on the rise. In the last three years the ratio of organizations that suspect or know that they've been recently hit by a breach related to components has increased by 50%.
A big part of the issue is that a large number of organizations today have no policies in place to govern what kinds of components can be used and how they can be used. For more than four in 10 organizations it is a bit of a Wild West mentality as to how components are consumed by developers.
"For those without a policy, there are no rules in place when it comes to 'good' vs. 'bad' consumption practices," wrote Derek Weeks of Sonatype. "Having policies in place can help to improve the quality of applications being produced, reduce vulnerabilities to attack, and eliminate use of components with risky license types."
Not only do organizations not have policies in place to govern when, how and what components can be used, they also lack the technical controls to ensure these kinds of policies can be enforced and to track when and where components are used.
The lack of tracking of components makes it easy for development teams to consume third-party components with a set-and-forget mentality. As a result, many old versions of open-source components linger within applications, so an old component vulnerability may get carried along into newer and newer versions of an application.
In one study done by Veracode across a wide swath of Java applications, the firm found that a major deserialization vulnerability that affected the Apache Commons Collections library in 2015 impacted not just the version in which it was first found--which was present in 26.3% of Java applications in mid-2016--but also five other versions prior to that. At the end of the day, 50.3% of all Java applications Veracode scanned contained components with this vulnerability.
Further complicating the issue is that finding component dependencies is more complicated than it might seem at first. Not only do organizations need to track component versions to accurately cross-reference their exposures to vulnerabilities, but there's also the issue that certain libraries and frameworks may be hiding vulnerable open source components and files that developers might not even be aware are present in their applications. So there are nested tiers of dependencies to consider.
"When we really dig into the most common components used in the enterprises, there are a lot of hidden surprises as dependencies come into play," Veracode experts wrote in its report. "This can pose a real challenge when tracking common component vulnerabilities."
Additionally, infrastructure components that are core to a programming language or platform on which the software is built upon can themselves be problems, according to Black Duck. This means keeping the Linux Kernel and programming frameworks on the radar as well.
Image Source: https://www.blackducksoftware.com/open-source-security-risk-analysis-2017
[Don't miss "Security In The Age Of Open Source: Myths & Perceptions" at Interop ITX, May 15-19 in Las Vegas.]
Further complicating the issue is that finding component dependencies is more complicated than it might seem at first. Not only do organizations need to track component versions to accurately cross-reference their exposures to vulnerabilities, but there's also the issue that certain libraries and frameworks may be hiding vulnerable open source components and files that developers might not even be aware are present in their applications. So there are nested tiers of dependencies to consider.
"When we really dig into the most common components used in the enterprises, there are a lot of hidden surprises as dependencies come into play," Veracode experts wrote in its report. "This can pose a real challenge when tracking common component vulnerabilities."
Additionally, infrastructure components that are core to a programming language or platform on which the software is built upon can themselves be problems, according to Black Duck. This means keeping the Linux Kernel and programming frameworks on the radar as well.
Image Source: https://www.blackducksoftware.com/open-source-security-risk-analysis-2017
[Don't miss "Security In The Age Of Open Source: Myths & Perceptions" at Interop ITX, May 15-19 in Las Vegas.]
It's been four years since OWASP first put third-party vulnerability risks squarely on the appsec map when it included the problem in its Top 10 list. But in that time, the risk has only grown as increasingly more applications today depend heavily on open-source libraries, frameworks, and other components, all with their own vulnerabilities.
It's a very large attack surface for applications today and one which has increased chances of security headaches. Here are some of the latest stats on this hidden problem.
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024