With open source components being used in more than 80 percent of commercial software developed today, ALM efforts must be altered to address them. Failing to do so may introduce unnecessary risks. This article outlines the potential risks associated with not managing open source as part of your ALM, and explains how these risks can be easily avoided.
Open source software is playing an increased strategic role in today’s enterprises. According to the 2015 Future of Open Source survey, two-thirds of respondents said their companies create software for customers built on open source, and more than that said they consider using open source software before other options. This requires us to make changes to our ALM efforts. It should not be hard or time-consuming, but it does require some attention. Without this attention, you are taking on several risks.
Risk #1
The first is not knowing what’s in your software. Open source components are perfectly safe to use, but they have to be managed, and to manage something, you need to know what it is. The biggest risk is not being aware of all the open source components that were added to the software in the development phase.
Knowing what’s in your software may not be as simple as it sounds. Most open source libraries rely on other libraries (dependencies). These may have different licenses and additional security vulnerabilities. According to research by my company, WhiteSource, more than a third of open source components depend on other open source libraries, and each of these has an average of nine dependencies. Being able to list all the open source components in your software is key.
Risk #2
The second risk is not complying with what the components’ licenses require. While open source components are free, they still come with licenses. These licenses are often permissive, but some may require you to provide your source code to anyone who wants it. An example of such a license is GPLv2, which is the basis for the recent lawsuit against VMware by one of the Linux kernel developers.
If you know what is added to your software, you can easily check what licenses you have to comply with. Here, again, knowing about all your components is key—according to WhiteSource research, 64 percent of libraries in use have dependencies with stricter licenses attached to them.
Risk #3
The third risk is finding restrictive licenses in your software when it’s too late. Integrating libraries from various sources with in-house written code into one working product is a serious challenge that requires time and effort. There is nothing worse than discovering an open source component that you cannot use (for legal or security reasons) in your software when it is ready to be released.
Knowing what open source components were added to the build in real time allows you to check whether they conform to your open source policy and decide if you want to use these components before too much effort is put into developing your software around them.
There are usually plenty of alternative components with friendly licenses your development team can consider, provided that they know that they should.
Risk #4
The fourth risk is security vulnerabilities and stale libraries. Open source software is like any other software—it has security vulnerabilities and bugs. The good thing about open source software is that there is an entire community using, testing, and fixing these components.
Our study of more than six thousand projects shows that if open source components are properly managed and regularly patched, more than 95 percent of projects would not include a known security vulnerability. So in this case too, knowing what’s in your software and what is added to it is crucial.
Avoiding These Risks
To avoid the risks above, developers, configuration managers, and DevOps should all take part in checking the open source components that are getting into the software. These teams need to:
- Check the library’s age, popularity, and recent versions
- See what licenses are attached to the library and what licenses are attached to its dependencies
- Take count of what known security vulnerabilities are in the libraries they want to use
These responsibilities should be performed in various stages of the ALM. During the development phase, developers should have an easy way to check components they want to use. During the build, the open source components that are added should be checked. Special cases such as libraries with known security vulnerabilities or unknown licenses should be reviewed and approved, and license compliance requirements (for example, mentioning the open source component that was used in the release notes) should be followed.
Open source components are convenient, well-researched, and cost-effective, so it’s clear why so many software engineering teams make use of them. However, care does need to be taken to avoid risk, so it’s important to make open source management part of your ALM. When using an automated process for all these tasks, it becomes simple.
About the author
Experienced entrepreneur with deep background in R&D and product management. At Eurekify. and later CA, became an expert in designing and implementing complex management and compliance software systems, and in delivering them to the market. Now co-founded and manages WhiteSource.
