As developers today, we stand on the shoulders of giants. By building applications on top of an existing landscape of established open source components, we can spend our valuable time innovating rather than reinventing the wheel. But there is a distinction between using someone else's code for inspiration and using open source directly without understanding the legal framework.
License restrictions#
If you do not follow the license restrictions associated with the open source code you are using in your product, you can open yourself up to not only bad public relations but some serious lawsuits. To help mitigate the risk, someone in your team needs to have at least a basic understanding of open source license restrictions. It helps to put in place an actionable list of best practice and methods to automatically detect open-source components that may find their way into your code base.
Developers should follow the licensing conditions for every piece of code that uses open source, including subcomponents, no matter how small. This can be confusing. There are hundreds of different open source licenses and each has its own unique usage conditions. However, most open source licenses can be split into just a handful of categories. 'Copyleft', for instance, usually require developers make source code and binaries also available under the same license, but for documentation, there are different licenses; and 'permissive' applies only minimal restrictions such as author attribution.
License Compliance in CI/CD Pipelines#
Before licensing considerations can take place you need to know exactly which open source components have found their way into your repository. Most companies we deal with do not know the full inventory of components they use, or manage the inventory in Word/Excel documents, hoping the documents are up-to-date, which is a little scary. That's where automated tools can come in. With the trend in the industry towards DevOps methods, it is now usual to have an automated toolchain which runs on each code check-in. The standard steps include building the software, testing (unit, integration and system level), and automated deployment to an environment that closely resembles that of release.
Image for post
By adding an extra step in this pipeline, which focuses on detecting open source components, you can get a good handle on any security vulnerabilities or licensing issues which your developers may inadvertently be adding. During my work at Verifa, a DevOps consultancy practice, we've seen odd pieces of code find their way into some serious applications. In one instance elements of an open source game with a copyleft license were being included inadvertently in an FDA approved medical device.
Once you know exactly which components in your system have been drawn from open source code, you need to have a compliance strategy in place to check that the components you intended to use legitimately are correctly licensed.
This will begin with keeping a record of the licensing terms that apply to each component you are using, and the dependencies that your system has on that component.
Architectural Overview
Many developers underestimate the importance of good software architecture. When you build an office block, you want to hire a good architect to be sure you will get a building with a solid foundation. This is also true in the software domain. Architecture is the root of good software, it helps you create solid foundations for your entire project to ensure that you can build something that is scalable, powerful and secure.
By visualizing the use of individual components, including open-source, in an architectural review, you can see visibly the dependencies on any component across the rest of your system.
The advantage of this detailed architectural overview is that when someone identifies a problem in a component at a later date, you can quickly determine the impact this will have on your product.
Security issues#
The cost of fixing security issues and bugs as they are identified in open-source components grows as the development cycle advances. It is helpful to uncover as many issues as possible as early as possible in the development process, to decrease the cost of fixing them and to improve the quality of the shipped product. You need an agile approach to open-source management by integrating tools directly into your build process and auditing your open source components every build cycle. Enterprises need to have a method to identify all instances of open-source code in the repository, update this list continuously, to push developers away from old, insecure libraries, and also to find and deploy patches and they are produced by the community.
One major advantage of using open source is the ecosystem. Usually, you can draw on the power of hundreds of developers looking at and improving the code base steadily, for free. Any security issues identified in the code are usually fixed quickly in popular packages. The catch here is that you need to apply these patches to your own product hastily, which you can only do if you know that you were using them. Unfortunately, small open source projects may not have the same advantage. Known security problems can persist for a considerable amount of time before a fix is implemented.
In today's world, we are constantly under the threat of cybercriminals who are looking to take advantage of any weakness in technology. Use of open source components with known security issues is one of the leading vulnerabilities in today's hi-tech society. There is also the risk that you can never be fully sure of the motivations driving the developers behind open source components. In a recent event, malicious code was found inside a popular open source library (https://www.theregister.co.uk/2018/11/26/npm_repo_bitcoin_stealer/). Only by being engaged in the communities behind the components you are using can you hope to mitigate such risks.
Software doesn't Age Like wine, it ages like milk.
In an ideal world, applications would update themselves as soon as a security patch becomes available, with no intervention required. In practice, this isn't always possible.
Isolate, Verify, Merge#
Aside from the technical aspects and advantages of monitoring your open-source use, it makes compliance with the licensing terms much easier. If you're using components which mandate delivery of source code along with your product, it may be necessary to isolate the open source component and call it from your own codebase using an API. This could sidestep the requirement to deliver your proprietary software as source code.
Some open-source software licenses have more simple requirements such as author attribution. The strategy to implement open source needs to have a handle on these requirements to allow you to deliver on them in a streamlined way.
Distribution#
Virtually all open source component licenses will have notice requirements. This means if you distribute a product which includes open source software you need to deliver a copyright notice, or sometimes even the entire text of the license that covers the software, with your own product. While these requirements are not usually difficult to understand, complying with them can be time-consuming. The last thing you want is to delay the release of your product when you're up against tight deadlines. Copyleft licenses go further, your developers will be limited in the way they can integrate the open source software with your custom code. These require either delivery of source code or the ability to send source code on request.
I've seen many companies realize that managing the use of open source can sometimes hinder rather than help the development of proprietary software. Trying to use open source, without some framework of automation, diverts both management and technical effort away from their true function of delivering innovative products to the market place quickly.
Tools
In the last decade, we saw a rapid evolution of automated tools that help identify, track, and manage the use of open source software. The best tools integrate well into a DevOps setting and combine with an architectural overview of the software you are developing.
Verifa has carried out extensive research in the tooling landscape and are involved in an open source project to help manage software components. SW360 is a Web application and a repository to collect, organize and make available information about software fragments. It establishes a central hub for software within your organization. By populating the SW360 with data about your open source usage you can track usage of components throughout your organization.
At Verifa we worked with WhiteSource to help populate the SW360 database for a client. WhiteSource is a great tool that helps with automation in CI/CD pipelines and identification of security vulnerabilities. You can use Whitesource with almost any build tool or package manager. It can help you in every step of the software development life cycle by monitoring the use of your open source components, even after you release. As soon as you integrate it into your pipeline, it works continuously and automatically behind-the-scenes, keeping track of your open source components.
By reacting quickly, at time zero, to vulnerabilities identified, you can mitigate the technical debt that unchecked open source can introduce to your project.
Expert Help#
Open source licensing can confuse if you're used to living in the world of proprietary-only software. For evaluating the technical and legal conditions of using open source components, ask for expert help. There are consultants who can help you understand how to combine open source software under different licenses and expedite the development of your own innovative proprietary code.
Likewise, on the technical side, there are people out there (including Verifa) who can help you implement automatic checks of your code and put in place a DevOps enabled quality gateway at every check-in.
Only by having visibility of your open source usage can you work to mitigate security and licensing issues around the use of open source components.
If you found this introductory Open Source Compliance article useful, Verifa have a more detailed paper here. This expands on the principles touched upon in this short article.
You are also welcome to sign up to the Verifa newsletter... You will receive notifications of other useful DevOps content straight to your inbox.
If you want to contact me directly, I can be reached here: amackay@verifa.io
