While vulnerabilities in open source code continue to make headlines, such as Other technologies, such as Heartbleed and Log4Shell, go unnoticed by a hidden source of open source risk - non-compliance with open source licenses.
Open source software licenses are a major source of risk, Palo Alto Networks believes, because even a single non-compliant license in the software can lead to legal action, time-consuming remedial actions, and delays in getting a product to market. Despite the obvious risk, being compliant with licensing regulations is no easy feat. The variety of open source licenses and the difficulty of determining which licenses apply to a piece of software makes it difficult to keep track of, understand and manage licenses.
As with searching for high-level or critical vulnerabilities, searching for non-compliant licenses requires organizations to unravel the web of open-source and transitive dependencies, often more than four or five levels deep. These dependencies often result in multiple versions of the same open source package, and it is not uncommon to find overly restrictive copyleft licenses tucked away in this web. To ensure licenses are compliant, organizations must leverage advanced, contextual analysis of software composition. This makes it possible to identify, detect and prioritize the non-compliant licenses that threaten the company.
Introduction to open source licenses
When users hear the term "open source", it's easy to assume that they can use this package however they want, e.g. B. by using it for the development of a commercial product. But even if the source code is open to the whole world, open source code is not free from usage restrictions.
Open source packages come with licenses governing use, reuse, sharing, modification, and distribution of the code. Hundreds of different open source licenses dictate how users can use open source code, and the penalty for noncompliance is real. If a company uses an open-source package and does not comply with the license, it could be forced to open-source its proprietary code or go through the costly and time-consuming process of removing and replacing the non-compliant package throughout the code base.
So how do those responsible know what specific requirements they need to meet to remain compliant? This is where it gets tricky, as the requirements vary greatly depending on the license. Some licenses – e.g. B. Copyleft - are very restrictive. Others, in turn, are subject to a fee, and others again can be used freely if the correct attribution is given. In general, however, open source licenses fall into two main categories: copyleft and permissive licenses.
Copyleft Licenses
Copyleft software licenses are very restrictive licenses that require companies to open source any code that uses the open source software in question. These licenses require them to distribute their software's source code files, which usually include a copy of the license terms and credit the authors of the code. The best-known copyleft license is the GNU General Public License (GPL).
Permissive Licenses
Permissive licenses contain only minimal restrictions on how the software can be used, modified and distributed. These licenses usually include a disclaimer of warranties. Some examples of permissive licenses are the GNU All-permissive License, MIT License, BSD Licenses, Apple Public Source License, and Apache License. In 2016, the most popular free software license is the permissive MIT license. A notable and successful open source software package that uses the Apache license is Kubernetes.
Case Study: Non-Compliance with Copyleft Licenses
In 2008, the Free Software Foundation (FSF) sued Cisco for selling LinkSys-branded software that was not compliant with the open-source code it was using. As is often the case, the non-compliant software that caused GPL copyright infringement was integrated into Cisco's software as part of an acquisition. With the ubiquity of open source software, the rise of acquisitions, and the depth of dependency structures, it is becoming increasingly difficult to identify open source licenses that are deeply entrenched in commercial software offerings. However, failure to comply can thwart efforts to keep commercial intellectual property private. For example, a company that does not comply with a license may be forced to open source its software or stop selling that software. And even if a license isn't as restrictive as a copyleft license, teams may have to rebuild their software to break a key dependency, which is costly and slows the speed of release.
License compliance monitoring
As if identifying all licenses wasn't complicated enough, an open source license can change at any moment. For example, the widely used open source package Elasticsearch switched from a formerly permissive license to a more restrictive one in 2021. Verifying license compliance is not a one-time thing. Instead, compliance management requires an ongoing approach that requires the same due diligence as other open source security processes, e.g. B. Updating third-party packages to newer and more secure versions.
Open Source Management Strategy
At first glance, complying with open source licenses may seem simple. In reality, however, it is as complex as the nature of open source itself. And the sad truth is, even if the existing open source security strategy includes a thorough review of dependencies and vulnerability management processes, there may still be significant openness -Source risks that companies don't address. Just a single non-compliant package is enough to render an entire application non-compliant with license requirements. Organizations must therefore incorporate a proactive and comprehensive open source security strategy into their strategy to adequately protect their supply chain. By taking a proactive approach that identifies and remediates open source licensing issues early in the development cycle, organizations can increase developer productivity. At the same time, they can reduce the stress of having to tear out and replace non-compliant packages from their software later in the development cycle.
Adopting comprehensive open source security can seem daunting, but it is doable. If done right, it can even be developer-friendly. By integrating open-source tools like Checkov with IDEs like VSCode and Jetbrains' PyCharm, application developers and DevOps teams can gain visibility into vulnerabilities and potential license compliance issues as early in the development cycle as possible. This allows them to proactively fix issues with non-compliant packages and maintain the speed of their releases.
More at PaloAltoNetworks.com
About Palo Alto Networks Palo Alto Networks, the global leader in cybersecurity solutions, is shaping the cloud-based future with technologies that transform the way people and businesses work. Our mission is to be the preferred cybersecurity partner and protect our digital way of life. We help you address the world's biggest security challenges with continuous innovation leveraging the latest breakthroughs in artificial intelligence, analytics, automation, and orchestration. By delivering an integrated platform and empowering a growing ecosystem of partners, we are the leaders in protecting tens of thousands of businesses across clouds, networks and mobile devices. Our vision is a world where every day is safer than the one before.