Taming Open Source Risk

According to the annual Sonatype State of the Software Supply Chain Report, open source software (OSS) consumption is growing at an estimated 33% annually across the primary OSS ecosystems – namely, Java (Maven), .NET (nuget), Javascript (npmjs) and Python (PyPI).

As such, it is important to understand the risks and benefits of using OSS and the role proper governance plays in enabling businesses to achieve their goals— while avoiding common pitfalls that can arise in the absence of an organized, proactive approach to OSS management.

Modern delivery best practices incorporate automation of continuous software composition analysis (SCA) scans within development pipelines to proactively manage risk presented by utilizing OSS. A passive approach such as a periodic audit may be disruptive or time consuming for developers and in between audits may expose the enterprise to significant risks that could be avoided.

What is open source software?

Open source software is software whose source code is freely available for anyone to access, and, in many cases, to maintain. Many applications, libraries and tools are compiled from open-source software and often these derivative products are freely available for consumers who do not wish to download and build free software themselves.

OSS will generally use one of several well-established standard licensing agreements which confer several rights and obligations to the consumer of the software. Some licenses are extremely permissive, while others may impose significant commercial (or other) restrictions on how the software is to be used. The license and the terms of use are usually included in the source code itself.

Usage of the source code implies an implicit acceptance to be held to the terms of the agreement. These agreements have the full support of the law in countries that recognize the agreements and are generally enforced in commercial contexts.

OSS is always consumed on an as-is basis: the consumer accepts all risks and liabilities with respect to the use of the software. There is no one to sue if the software does not behave as expected. In order to manage this risk, some commercial enterprises offer commercial support for free software, adding a layer of protection if use of the OSS results in business needs not being met.

Open source benefits

Modern software is almost impossible to build today without relying on a considerable amount of open source software. This is because many of the common software building blocks, which historically may have been provided by third party software providers, are now available as OSS. For every commercial library or reusable software component, there are likely several free or OSS alternatives.

Traditional software licensing has become more expensive, and is not as amenable to modern, scalable, cloud-native architectures, since licenses are typically tied to characteristics such as CPU cores, servers, or individual users.

Software asset and license management has become more complex and supporting older versions of software used by customers has become increasingly more difficult. In addition, the lack of transparency around the code used in proprietary software components sometimes exposes enterprises to significant vendor risk, as well as a security risk.

While enterprises that depend heavily on third-party platform architectures may not directly use OSS, it is highly likely that the third parties themselves are heavy users and/or contributors to OSS.

In general, most OSS is funded through software firms that profit in some way from their use of OSS, although many OSS projects are supported entirely by the community of individual developers that use the software they contribute to. Increasingly, commercially grounded open-source communities, such as the Cloud Native Computing Foundation (CNCF), are being established to help get fledgling OSS projects established.

Open source risks

OSS presents several risks to enterprises, both from the perspective of how it is consumed, and the extent to which it is contributed to.

OSS consumption risk  

The principal risks in relation to the use or consumption of OSS are as follows:

Security risk 

The risk that the software includes a vulnerability that exposes any software component that uses it. Vulnerabilities can be identified at any time in the lifecycle of OSS.

Compliance risk  

The risk that the software is used in such a way as to be in breach of the licensing agreements associated with the software.

Maintenance risk  

The risk that versions of the software being used fall so far behind the latest maintained version that they cannot be easily updated and/or replaced — either to take advantage of new features, or to address security or compliance risks.

Some risks can be mitigated through using commercial providers that support the OSS, but most risks can only be effectively addressed through effective internal IT governance.

OSS contribution risk 

In general, organizations that consume OSS should also be prepared to contribute back to the community. Organizations that only consume OSS software often make changes that are specific to their needs. This is called a “fork” as it involves creating a new branch of code which is no longer maintained by the OSS community. Often, it is not even visible to the OSS community if enterprises keep the code in the branch private.

Over time, this constitutes a significant risk, as the OSS software risks becoming a critical liability to the enterprise, and the cost of maintaining and supporting it increases.

It is recommended that along with a policy for consuming OSS, enterprises also have a clear policy for contributing to OSS projects, and where possible avoid creating forks of OSS projects unless there is a clear strategic need. 

The risks of individual employees contributing source code updates to an OSS project are minimal, provided the OSS license terms provide the necessary liability protections. However, OSS code change reviewers are not obliged to accept code submissions from any organization, and enterprises should be prepared for OSS changes that deviate from their needs.

In these circumstances, enterprises can consider being a formal sponsor of the OSS project and having a say in what code gets in and what does not. While this does make the organization a desirable place to work for highly skilled OSS engineers, it also presents some reputational risk, as the organization is obliged to commit to its role as OSS sponsor and steward, and its activities in this space will be very public.

Governance strategies

To effectively manage the risks associated with the use of OSS, different techniques are needed for the different primary risks. The key risk governance activities required are as follows:

Various techniques for managing these risks exist and are beyond the scope of this introduction to describe, but increasingly a variety of tools (including, but not limited to, portfolio tools such as CAST Highlight) are available to greatly reduce the overhead of managing these risks.

Tooling and automation

Automation of OSS governance is based around two main use cases:

• Governance of the use of free OSS-based software.
• Governance of the use of OSS code in custom applications

For most non-development use cases, the simplest approach is to ask OSS users to self-declare their use of OSS, and to give them an indication if their usage is compliant or not.

More advanced solutions can provide automated guardrails that can prevent unauthorized OSS components from being deployed and can provide detailed audit logs of where OSS components are being used and the level of compliance of those components. This includes the generation of ‘software bill of materials’ (SBOMs) which are increasingly being required to provide software supply chain assurance.

Open source offers enterprises a great opportunity to accelerate the delivery of valuable technology-enabled capabilities, but it does come with some costs and risks that organizations relying on OSS should be aware of.

Protiviti recommends that technology organizations formally introduce governance of open-source components as part of their overall technology strategy governance.

Organizations which are unsure of the risk they are exposed to with open source should conduct an audit of where and how OSS components are being used and assess if the risk falls within the organization’s risk appetite.

Organizations who judge that OSS-related risks exceed their risk appetite are increasingly creating a formal open source program office (OSPO) to help manage open source-related risks. In these cases, formal policies around open source governance should be established in collaboration with enterprise legal functions and communicated to the wider organization. Tools and services should be provided to help facilitate compliance with policies as part of modernized technology delivery processes.

With these basic steps, organizations can realize the full benefit of using OSS and be confident their OSS-related risks are being effectively managed.