Since Apache Maven, the brainchild of Sonatype founder Jason van Zyl, emerged as a top-level Apache Software Foundation project in 2003, the Central Repository has become a primary source of open source components. Jackson says the Central Repository receives four billion requests per year for its 300,000 components.
But after crunching the data on how the Central Repository’s components are used – with the help of application security specialist Aspect Security – Jackson says he believes organisations need to be much more diligent in their practices around open source components because many are exposing themselves to risk by deploying older, vulnerable versions of components.
Global 500 Firms Downloaded 2.8 Million Insecure Components
Aspect Security’s study of Sonatype’s data found that more than 80 percent of typical software applications are open source components and frameworks consumed in binary form, and that Global 500 organisations, collectively, downloaded more than 2.8 million insecure components in one year. The average enterprise downloads more than 1,000 unique components from the Central Repository each month, and large banks and independent software vendors (ISVs) download even more. And many of the most popular components displayed flaws.
Known open source vulnerabilities.
Source: Aspect Security’s Study of Sonatype data.
The study found there were more than 46 million downloads of insecure versions of the 31 most popular open source security libraries and frameworks. For instance, Google Web Toolkit (GWT) was downloaded 17.7 million times with known vulnerabilities. Other popular vulnerable libraries downloaded included Xerces, Spring MVC and Struts 1.x.
In many cases, newer, patched versions of the components or frameworks were available, but users downloaded insecure versions anyway. The study found one in three of the most popular components had older, vulnerable versions that were still commonly downloaded, even when a newer version with a security fix was available.
“The rates of consumption of flawed components were shocking to us,” Jackson says. “I think the root reason for that behavior must be a lack of awareness driven by a lack of notification infrastructure.”
The Issue Is Notification, Not Open Source
Jackson’s issue is not with the open source model itself. “I have been for years and remain a huge advocate for open source,” he says. “I think the pace of innovation, the ability to leverage other people’s innovation and the transparency and many-eyeballs theory makes open source much more secure over time. What we are trying to point out is not whether open source is better or worse than commercial software or whether open source is fundamentally flawed.”
Instead, he says, the issue is that the open source ecosystem lacks the ongoing relationship between vendor and customer that has evolved in the commercial software space. The commercial software world has become used to patch management, update management and even events like Microsoft’s Patch Tuesday, when the Redmond-based software behemoth regularly releases security patches for its software. In the open source world, the onus remains largely on the consumers of open source components to track the status of the releases, patches and fixes issued for the components they use.
“The data clearly show that organisations consume huge numbers of vulnerable libraries,” says Jeff Williams, CEO of Aspect Security. “While the numbers from this report are alarming, the take-away is clear–open source software is critical to forward-thinking development organisations, but there must be education and control to accompany its usage.”
Best Practices for Remediation
The troublesome nature of the situation becomes even clearer when you consider the viral nature of the open source component ecosystem. A single open source component can be reused in dozens or even hundreds of other components, meaning that a flaw in that component will then be inherited by every component that depends on it. For instance, a security vulnerability in Spring-beans 2.5.6 affected 1,447 dependent components and untold thousands of applications. Even when Spring-beans was updated to fix the vulnerability, there was no process in place for updating the ecosystem, meaning hundreds of components remain flawed.
The first step to getting this situation under control is to put together an inventory of open source components used in production applications. And the inventory needs to contain information about component dependencies as well. You need to track component downloads and usage to understand consumption and inventory internal component repositories to determine what is being distributed to development teams. And you need to monitor application bills of materials for updates and newly discovered vulnerabilities. As it stands, 48 percent of organisations don’t maintain such an inventory at all, and another 20 percent maintain an inventory but don’t keep track of component dependencies.
Once you’ve taken that step, you need to analyse your component repositories for vulnerable components and your key applications for known security vulnerabilities.
Finally, you must establish controls throughout the development cycle. Jackson suggests establishing policies regarding security, the use of viral licenses and out-of-date or out-of-version components. He also suggests eliminating or blacklisting known vulnerable components in internal repositories and establishing mechanisms to prevent known flawed components from entering the organisation.
