Tom Sweet - Contributor VP Cloud Services, GM Financial

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.

Open-Source Risks

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

1. Educate your legal and contracts teams on risks and concerns. Agree on a set of license agreements which your company is comfortable with. You may consider starting with the MIT and Apache 2 licenses because many of the large OSS packages, including Microsoft’ use them.
2. Invest in OSS management tools. Auditing and scanning for OSS manually is not realistic in the enterprise, and if you have in-house development teams, the landscape changes daily. Most developers do a great job finding open source, but are not so great at reading licenses, often just clicking “Accept” when presented with one. Acquire the tooling that is the best for your needs, such as Sonatype Nexus, Synopsys BlackDuck or something similar. As your teams move to continuous integration and DevOps, ensure these tools are included in your DevSecOps pipelines to ensure that licensing, vulnerabilities, and encryption are scanned for compliance. Work with your cybersecurity, software, and governance/risk/compliance teams to agree on a level of risk and stick to it! Hold the development teams accountable and reject any software build that exposes the company well before production.
3. Create an internal education program to teach the IT team how to use the new tools along with reasons why. This would be a similar program to the phishing education programs that cybersecurity teams deliver to the enterprise.
4. Give back to the open-source community. Once you are sure that you have the above covered and have the tooling in place, you will eventually find vulnerabilities in the OSS your teams use. While many issues will already have available fixes, others you will need to fix yourselves. Once you fix these, you should then share your fix back to the specific open-source community who maintains the project. This is about more than just being a good citizen in the open-source world though. If you do not do this, you will be forever “forked” between later versions coming from the open-source community and your custom version that you must maintain, and which requires constant syncing. This is not sustainable long-term for even one package.
5. Consider releasing some applications or projects as open-source. Many times, teams create internal tooling or other software that is not especially proprietary and can be shared. By posting to a site such as GitHub, you can not only give back, but you can see who from outside your company is contributing to your projects. These contributors may be the type of talent you wish to hire. These online projects establish your company as a leader, creating a following of contributors. Much of the top talent wants to work with open source, so recruit from your own OSS projects.

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.