While these components can dramatically accelerate software development, they also carry inherent risks, from application failure and security vulnerabilities to legal risks.
Mark Troester, director of product marketing at Sonatype, talked about those risks last week during a session at the DevOpsDays conference in Atlanta.
Sonatype operates the Central Repository, the industry’s primary source for open-source components. In many cases, 80 to 90 percent of the code in new applications comes from existing open-source components. Over 9 billion components will be downloaded this year from the Central Repository, a fact that underscores the fundamental shift from writing to assembling applications.
Sonatype’s business is what it calls Component Lifecycle Management (CLM), tools that provide a better framework for managing all that existing code as it is assembled to perform new tasks. The aim is to reduce failure and security vulnerabilities throughout the creation of new software.
Troester says organizations are starting to leverage CLM for describing metadata about components and their use throughout the software development process.
So how risky is open-source code? A study by the security research firm Aspect Security evaluated 113 million downloads of 31 popular open-source components, frameworks, and security libraries from the Central Repository.
These were downloaded by over 60,000 organizations, including most of the Global 100. They found that 26 percent of these downloads were of components with known vulnerabilities. Because most modern applications have dozens or hundreds of libraries, this research showed that the probability of having at least one vulnerability in your application due to a known insecure library is over 95 percent.
Many software vulnerabilities are found in libraries and components after software is deployed. Since complex sets of enterprise applications could be built across thousands of components, it can be challenging to determine if a newly discovered vulnerability relates to existing code.
For example, the FBI recently put out a briefing regarding “multiple remote command execution vulnerabilities” discovered in several versions of Apache Struts 2 framework widely used for enterprise applications.
Challenges of Tracking Complexity
Troester says organizations are having trouble managing component risks owing to difficulties in keeping pace with the status of new components – and subsequent versions.
“We are talking about moving apps from development into QA and production, and to be able to cycle through those quickly,” he says. “If you don’t have release management process to weed out problematic components, then component flaws will get into applications.”
A CLM-aware release management tool could fail a build, or transition the status of an app in production, when a problem with a component is identified. Even after the software is built, new vulnerability of failure reports about a particular component or library could trigger an alert to address this problem before it impacts the business.
CLM also promises to help shift the development process left by guiding developers in understanding the known flaws of component versions.
Says Troester, “We want to find and fix problems earlier in the software development process. If you can start with the right component, then you don’t have to do a downstream revision in the development process.”