7 Best Practices for Managing Open Source Components

This is a guest article by Limor Wainstein from Agile SEO.

Let's begin by answering the question: What is open source software? Open-source software has source code that is accessible to and modifiable by anyone, and the software is shareable for any purpose. The Open Source Initiative (OSI) provides a full list of official criteria for defining software as open source, some of the main points of which are:  

• Open-source software must include source code and must allow distribution in source code as well as compiled form.  
• An open-source license must allow modifications and derived works. 
• The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. 

Open-source components are software units with well-defined interfaces and explicitly specified dependencies, and they meet the open-source definition provided by the OSI. You can view these components as blocks of reusable code, ranging in size from code snippets to libraries and classes to separately running processes.  

Examples of popular open-source components include TensorFlow (an open-source library for dataflow programming and machine learning), Apache Spark (an open-source framework for Big Data analytics, and Node.js (an open-source JavaScript server environment).  

Developers often use open-source components to help quickly build and deploy applications. Modern development environments are high-pressured and focused on agility, and developers find they can do things quicker and better if they assemble applications using a variety of well-built, third-party components.  

A 2016 report found that 80 to 90 percent of today’s software applications are made of component parts, and increasingly, open-source components. If you are one of the many developers who use open source components in your apps, it’s imperative you understand open-source security and its importance. In this article, you’ll find a vital discussion about open source-security followed by seven best practices to help you better manage open-source components during your development work.  

When you consider that one in sixteen open-source components contains a security vulnerability, it’s not difficult to see how the widespread use of these components introduces security risks into applications. A single vulnerable open-source component means an entire at-risk application.  

Introducing security risks into open-source applications presents problems both at the enterprise-level and at the individual developer level. For the organization, there are significant compliance risks and high business costs associated with releasing vulnerable software. Developers can experience huge delays in projects due to technical debt arising from not applying regularly released updates to all open-source components. Often, a developer won’t even know that a given open-source component is vulnerable. 

So, what can you do to improve open-source security?  

The issue isn’t so much with using open-source components as it is with organizations and implementing inadequate supply-chain management procedures for software.  

In general, open-source components are as safe as their proprietary counterparts. Security issues arise when developers use outdated components in applications for which there are known vulnerabilities, often through no fault of their own. 

Some positive steps to take for better open-source security include:  

• Keep a complete and accurate inventory list of open-source components.  
• Identify new vulnerabilities in your software promptly after they emerge.  

An open-source asset management platform can help you maintain visibility over all open-source components and licenses, while other tools can automate various aspects of open-source security. For example, creating your own inventory of open-source components is likely to lead to inaccuracies because some components are not being documented. Additionally, it is tedious to manually go through vulnerability databases and check if any vulnerabilities affect components listed in your inventory.  

Automation, which a good software composition analysis tool can provide, is vital for better app security in teams using DevOps practices.  

1. Prioritize a Policy

The very first step to take when managing open-source components is for the organization to outline a policy on its usage. Without a policy in place, developers given free rein to choose any components cannot be blamed when issues emerge, whether with vulnerabilities or incompatible licenses.  

Establishing a clear usage policy from the outset prevents potential issues with managing open-source components from emerging down the line when such issues tend to be more time-consuming and costly to address.  

2. Update Promptly

Any time a bug is found and fixed in an open-source project, it’s a race against time to ensure you apply the relevant updates to all applications that use libraries or frameworks from those projects. Attackers move quickly when these types of bugs are found, and you must be ahead of them. Your ability to promptly apply updates depends on the visibility you have over all open-source components.  

3. Emphasize Quality

As a developer, you might feel tempted to choose only open-source components you or your colleagues/friends are familiar with. However, it is advisable to shift your focus to component quality above everything else, even familiarity.  

Relying on familiarity is no guarantee of quality: The infamous Heartbleed Bug was found in OpenSSL, a cryptographic open-source software library used by an estimated two-thirds of web servers worldwide at the time of the bug’s discovery. 

Quality assurance is a challenge in open-source development because there is no agreed-upon definition or set of standards regarding quality. Indicators of reliability and stability in open-source projects include the number of open bugs for each version, the number of bugs fixed in each version, and the severity of bugs. You could also look at the number of commits for an open-source project over time because this serves as a good indicator of how active its community is and how many developers are actually working towards improving the code.  

4. Use a Binary Repo Manager

A binary repository manager is an essential tool for managing open-source components. Such tools let you cache local copies of open-source components, which makes frequently used packages available even during times of external repository outages.  

Furthermore, you can segregate approved third-party artifacts from those that have not yet been approved, improving visibility and control over open-source components. You can even remove and prevent access to certain libraries, thereby preventing non-compliant artifacts from ever being created in your projects. 

5. Participate in the Community

As a developer, it makes sense to never ignore the community aspect of open-source projects. Neglecting to give back to a community that has simplified your job as a developer is not only a narrow-minded approach, it’s actively detrimental to you, the clients you code for, and the open-source project itself.  

Consider the scenario in which you find a bug in an open-source component and you quickly fix this bug in only your local copy of the component without participating in the community.  

A more effective approach is to search for the bug in the issue queue of the project, submit a bug report if you can’t find the bug in the issue queue or bug-tracking software used by the open-source project, and lastly, submit your fix to the community. The last step ensures your fix, or perhaps an even better fix for this bug is put into the "official" product, which means you no longer have to maintain it. 

6. Control with Build Tools

Continuous integration pipelines built with CI tools like Jenkins also help you closely monitor and control security vulnerabilities in open source components. You can easily track the commit that introduced a potential security flaw and fix it, which introduces automation to open-source security management. 

You can extend the functionality of Jenkins in terms of managing open-source components by integrating it with software composition tools to monitor and control all open-source licenses, including dependencies.  

A huge issue with companies and developers using open-source components is a failure to implement some sort of procedure to ensure applications comply with relevant open-source licenses. After all, every single open-source component and all of the components on which each depends has its own specific license that must be complied with.  

In June 2013, German company Fantec was found to have violated its obligation in the GPLv2 open source license to provide to its customers the "complete corresponding source code" of the software it released. The issue emerged after the company relied on its Chinese suppliers stating that the distributed media player it supplied included all complete source code. 

Maintaining visibility over open-source licenses, dependencies, and compliance issues is a complex task that can be made much easier with a CI server such as Jenkins and a plugin that tracks and detects compliance problems. 

7. Fork When Possible

One of the great benefits highlighted in the open-source definition is that you have express permission to take a copy of source code from an open-source project and independently modify it as you wish. Forking enables you to track changes made to open-source components since you will always have a link to the original repository.  

However, you must carefully consider that creating a private fork means taking on the burden of having to merge any changes made on the upstream version of the component. This burden increases the more your forked components diverge from the original. A good scenario for forking is one where you fork an open source component from a project that you don’t expect to be updated much in the future.   

Wrap Up

Open-source software and components are important enablers of agility in modern development environments. Practically all developers use open-source components in applications, whether at the front or back end; there is a library for pretty much any stack you can think of. Developers can use these components to make their jobs easier and allow them to focus on organization-specific challenges, including building the core proprietary software features that add value to enterprise applications.  

Developers who understand open-source security and how to best manage open-source components are more likely to efficiently and prudently use these components when building proprietary software.