A recent report indicated that Linux and other open source software (OSS) are emerging as serious malware targets. The report is a helpful reminder of the need to carefully consider the terms and conditions of OSS licenses and the resulting risks assumed by both software developers and end users in using OSS, including as it relates to cyber security. The increasing occurrence of cyber attacks should be a significant concern for most organizations. Understanding how OSS is licensed, and developing appropriate open source policies, is an important part of an organization's overall solution for managing cyber security risks.
The Nature of OSS
The appeal of OSS is obvious. There are many useful and widely used OSS solutions that are available for free, saving developers time and money (and often, but not always, providing code that has been honed and validated by a broad community of developers). As a result, OSS is ubiquitous in datacenters, on desks, and in pockets as major components of popular operating systems, platforms, applications, tools and software-based services.
Understanding OSS Risks
Although there are clear benefits, OSS also presents unique challenges and considerations for organizations that use it. For example, intellectual property issues with OSS have long been a concern for proprietary software developers. Most notably, the terms of "viral" OSS licenses (such as the GNU General Public License [GPL]) require, in certain circumstances, that the source code for the developer's internally developed proprietary software must be shared with the public, which would give the world an open look into how the propriety software works and make it easy for someone to create competing software. Uncertainty around whether internally developed proprietary software is subject to such sharing requirements can significantly reduce the value of an organization's intellectual property. Good OSS policies can manage this risk by creating a standardized approach to using OSS within an organization. Creating an effective policy will require an understanding of whether and how a virus could be triggered under the various OSS licenses.
Understanding and Mitigating OSS Security Risks
An organization's OSS policies and its understanding of OSS licenses, however, should address more than just intellectual property rights. As OSS use grows, we see more and more instances where it has resulted in cyber security vulnerabilities and has become a target for attackers. The 2014 Heartbleed bug in the OpenSSL library is one notorious example. OpenSSL is used to secure internet (and other network) communications and is ubiquitous in internet infrastructure. As a result, many popular websites and services, and infrastructure like routers, were affected by the Heartbleed bug. More recently, the Equifax data breach began with a bug in Apache Struts, an OSS web application framework.
In order to address cyber security risks in OSS, organizations need to understand other key aspects of OSS licensing, particularly as it relates to warranties and disclaimers of warranties. For example, most widely used OSS licenses state that the OSS is provided "as-is" and without warranty. As a result, there is likely no remedy for the developer for any security vulnerability in the OSS used by the developer. If the developer then integrates the OSS with its internally developed proprietary software, and licenses the combined software to customers, the developer may in turn wish to disclaim any warranties relating to the integrated OSS in its agreement with the customer (and otherwise provide that the OSS is subject to the terms of the original OSS license, not the terms that apply to the developer's proprietary components of the licensed software). Where this is done effectively, the customer may, subject to the remaining terms of the agreement with the developer, also have no recourse for security flaws in the OSS components of the software provided by the developer.
So, developers will want to ensure that their agreements with customers properly capture the extent to which the developer is willing to bear responsibility for any security or other flaws in any integrated OSS. Customers on the other hand will want to understand the extent to which the software that they are getting from the developer contains any OSS and what terms and conditions govern that OSS. The customer may wish to negotiate with the developer on this point and/or consider other ways to address the OSS security risk.
Further, security is an ongoing endeavour. Software and services must adapt to new threats and fix newly uncovered vulnerabilities. Abandoned or neglected OSS projects, or even widely used but relatively lightly supported projects like (at the time) OpenSSL, should be weighed against this potential security risk. Also, there are the practical issues of monitoring when fixes are released and how the OSS components will be updated. This will be a concern for the developer and/or the customer depending on the extent to which the developer, in its agreement with the customer, has accepted responsibility for any OSS components of the software provided to the customer.
A comprehensive OSS policy, based on a solid understanding of OSS licenses, can standardize the use of OSS in an organization in a way that identifies and mitigates the risks of using OSS, including security risks, while leveraging its benefits.
