Manage Learn to apply best practices and optimize your operations.

Take inventory of your open source software security

Developers love reusing code, whether it’s an open source library or a code snippet copied from the Internet. This expert tip looks at the best ways to secure and monitor component-driven software.

The majority of code in modern software applications is open source, pulled from the Internet for free and included in a project with just a couple of mouse clicks. To speed up build cycles, many developer tools and code compilers can automatically retrieve components and related libraries from the Internet and other repositories.

So what’s the problem? Complex applications built this way pose numerous threats: A high percentage of open source components that are downloaded contain known security vulnerabilities, according to a 2014 Sonatype Open Source and Application Security Survey. Attackers can also compromise the host servers such as Sourceforge or GitHub and replace the open source components with malicious copies.

To mitigate the risks of vulnerable, and even malicious, components, enterprise development teams should create in-house repositories. This tip looks at the best ways for IT security to track and supervise the ongoing use of open source code to ensure it’s a benefit, not a risk.

One central location

An in-house repository provides a central point for the management of software components and their dependencies. Advanced repository systems allow IT security and development team managers to enforce policies regarding recycled code:

·        Only approved components can be downloaded into the repository from a trusted source.

·        Developers’ tools must be configured to only allow usage of components from the in-house repository in assembled applications and other software projects.

This approach to open source software security removes the risk of compromised downloads from external repositories and ensures a validated and stable version of the code is available for use by enterprise developers.

Repository managers such as Sonatype Nexus and the open source Subversion can help integrate component lifecycle management into the application development lifecycle. These tools provide an inventory of the usage of open source components, many with complex dependencies, in internal repositories and production applications. In addition to alerting managers to any newly discovered vulnerabilities, repository managers make the ongoing monitoring of production applications easier – a major failing of many project teams.

Usage policy and governance

While a repository manager certainly simplifies component and code management, projects still need to be run with a policy in place to regulate code use and avoid any confusion over who is responsible for open source governance. Files that exist only in one central location greatly reduce a production application’s or project’s attack surface; however, IT security and development team managers should consider adding security wrappers around components to disable unused functionality. To ensure functions are used correctly, managers can restrict developer access to certain libraries, allowing only those who have passed relevant training modules or signed agreements to show they have read the appropriate documentation. Google, a major force in the open source movement, enforces a company-wide coding and comment style so developers can more easily follow each other’s work, essential when thousands of developers are accessing a single monolithic code tree.

Many open source libraries and packages include example configurations and code snippets. While useful, they are often not written with security in mind as they tend to be simplified in order to explain how a function or feature works. IT security teams need to ensure developers don’t simply cut and paste examples without having read the relevant documentation which, will cover security aspects of a function or settings in more depth.

Application developers should never assume that data has been correctly validated, especially if functions developed in-house receive data passed by a third-party component. The data may have been validated against a different set of requirements or rules. For example, a function to retrieve and display a user’s telephone number from a database may accept + and () symbols, but if it then passes the data to another function that actually calls the number, these characters could cause the process to fail if they are not removed.

Emergency response

The Open Web Application Security Project (OWASP) has flagged recycled code as a major vulnerability in the application development process. As application developers grow more dependent on open source components, the security problems  will only get worse if steps aren’t taken to control their use. Enterprises should deploy a well-managed revision control and component repository to prevent poor third-party source code management from compromising existing and future software projects.

Vulnerabilities found in open source frameworks and component libraries are rapidly exploited by hackers as they can automate their attacks knowing that any applications built using the flawed code are vulnerable until a patch is released and installed. Software development teams should have an emergency response prepared, to provide a rapid reaction to any critical patch releases for components in use.

Next Steps

For more on open source security and governance, check out Michael Cobb’s in-depth coverage of management strategies and open source policies after Heartbleed

This was last published in September 2014

Dig Deeper on Open source security tools and software

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.