Do Insecure Open Source Components Threaten Your Apps?

Open Source components are a boon to developers, allowing them to efficiently write code without reinventing the wheel. But since open source lacks the notification infrastructure of commercial software, organizations must maintain a running inventory of open source components and their dependencies in production applications or risk deploying apps with known vulnerabilities.

Fri, March 30, 2012
Page 2

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 organizations 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 organizations, 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 organizations 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 analyze 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 organization.

Thor Olavsrud is a senior writer for Follow him @ThorOlavsrud.

Our Commenting Policies