The software of today is built using open source. A 2020 Open Source Security and Risk Analysis report by Synopsys states that 99 percent of 1,250 audited applications contain at least one open source component. Some of the most popular programming languages today, including .NET Core and Node.js, are open source, along with Docker and Kubernetes, the two hottest applications for containerized applications and workloads.
One particular “chat” application found on GitHub has over 1,600 OSS components. It is not uncommon to have 10 or more different versions of the same component in various applications across the enterprise. Total component count can often be measured in the tens of thousands because OSS is cascaded inside other OSS, and what you thought was one component may in fact be 200.
The first OSS risk to understand is the use of vulnerable software components. Just like commercial off-the-shelf (COTS) software, OSS can have bugs. Often, these vulnerabilities are addressed quickly in a newer version or release. Unfortunately, consumers of the older versions may not be aware of either the vulnerability or the available update. Remediating vulnerabilities in your environment may introduce a whole lot of unplanned work, and as a result, delivery can be delayed. With potentially thousands of open-source components in use in an organization, keeping up with all the vulnerabilities can require a small army.
The second risk involves OSS licensing. The chat application mentioned above had over 100 different license agreements within its internal components. OSS license agreements can be complex, but they generally fall into one of two groups: permissive and copyleft/restrictive. If you choose to distribute your software, permissive licenses allow you to distribute the OSS without any substantial restrictions on licensing. Copyleft requires you to offer any source code created with that component available under the same licenses. Copyleft means that all the code your developers wrote for your new whiz-bang application needs to be given away for free, but if you use permissively licensed OSS you do not have to do this.
An additional risk arises when using abandoned versions of OSS. These versions create problems if they contain security and other vulnerabilities, and no one in the community is maintaining them.
A company needs to understand its software supply chain - what all the components are and where they come from. According to the Sonatype's 2019 State of the Software Supply Chain Report, 79 percent of organizations not practicing DevOps do not have a software bill of materials. Industry best practice is to use tools such as Sonatype Nexus or JFrog Artifactory to store local copies of the components needed to build applications. Then, if an Internet outage occurs and your team is temporarily unable to get to the open-source central repositories, you will have cached copies locally, which supports your business continuity/disaster recovery plans.
Open-Source Action Plan
When creating value for your business partners, speed matters. Reinventing the wheel by not using OSS only causes delays and lost opportunity costs. Open-source software is an accelerator.
Thomas J. Sweet is VP Cloud Services at GM Financial. Sweet is passionate about Digital Transformation, DevOps, Agile, Cloud, and attacking the talent shortage head-on by investing in his teams. His views are his own and not that of his employer, GM Financial.