Gartner's report, Technology Insight for Software Composition Analysis, makes four recommendations to improve software security. The first is to ensure a software bill of materials (or SBOM) exists for every software application; an SBOM illuminates all component parts and assists with rapid remediation, when necessary. The second recommendation is to "harden" the software supply chain; in other words, reinforce all internal and external code so that the entire system is more resilient.
Gartner's third recommendation elevates governance of open source software (OSS) licensing. OSS licensing is an important governance consideration. Its management is central to secure development. Operating without license compliance, intentionally or not, invites peril.
Governing open source licenses
Virtually all contemporary, proprietary software incorporates OSS components. Most open source components include licenses. (OSS without an explicit license should never be used because the authority to do so is unclear.) So how could these licenses be overlooked, ignored, or dismissed? It starts with the sheer volume of OSS in a typical application. Writes Gartner:
“One vendor-conducted study revealed 96% of codebases examined contained at least some open source, and 40% of those packages contained at least one high-risk vulnerability. In most modern DevOps development projects, the majority of code used in an application is made up of open source — with the remaining code largely serving as “glue” to assemble and invoke the various functions.” Emphasis added.
Only 12% of Gartner respondents selected licensing issues as their number one concern. Yet, the dangers of ignoring or misusing licenses are more insidious than they appear at first glance.
Risks associated with misunderstanding OSS licenses
An OSS license grants others permission to modify, use, and distribute software under certain conditions. However, every component is released with a different license, and a different set of terms. With hundreds or thousands of these components in a typical software supply chain, it is easy to see how complications arise.
Commonly understood problems borne from incorrect use of OSS licenses include:
-
Owing credit and/or renumeration to the contributing developer(s) or project teams
-
Requirement that proprietary software using OSS be returned to the commons with OSS licensing
-
Intellectual property disputes based on license incompatibilities between components or competing corporate interests (recently explored in the New York Times article, Prime Leverage: How Amazon Wields Power in the Technology World)
Yet, development velocity and competitive innovation demand the use of open source. Rather than relying on in-house developers to write code, open source allows you to tap into hundreds or thousands who contribute to public projects.
Companies should set license policies and evaluate all incoming components against them to avoid license problems. An "approved" list of open source components protects developers from incorporating components with problematic licensing. This removes or dramatically reduces license risk later in the development process.
Gartner writes:
[W]here policies are more ad hoc or absent, systems should be routinely scanned for problematic licenses (as determined by organizational policy, as set by appropriate stakeholders) and flag issues. If discovered, the presence of a proscribed license would be cause to generate a defect ticket, or break a build, if an especially risky license appears within a codebase.
Four questions to ask to ensure license risk avoidance
Jerry Gergel of Sonatype summarized common OSS licenses in a Nexus User Conference presentation. He sorts them into two broad categories:
- Permissive or Liberal Licenses (very simple)
- Use the code as you see fit
- Use at your own risk
- Acknowledge the author(s)
Examples include: BSD (Berkley Software Distribution), MIT, and Apache 2 licenses
- Copyleft (adds requirements)
- The source and the derivative must be under the same copyleft terms
- If you distribute the binaries you must make the source available
Examples include: Affero GPL (AGPL), GPL, Lesser GPL (LGPL), Mozilla Public License (MPL), Eclipse Public License (EPL), and Common Development and Distribution License (CDDL)
Jerry offers four questions any organization should ask when evaluating license risk:
- What is "distribution" and how does it relate to my organization?
- How do open source licenses affect patent rights in software?
- What is the "notice" requirement and how do we comply?
- Do we have "derivative work" and, related, does incorporating GPL code into my proprietary code cause the proprietary code to be licensed under GPL?
If you are answering these questions, you are managing your risk well. Watch Jerry's presentation, below, for well-known examples of OSS licenses risks. Companies like Cisco-Linksys, Best Buy, Samsung, and Versata offer cautionary tales.
Try Sonatype Vulnerability Scanner
Instantly generate an inventory of open source and third party components, and licenses, with the free Sonatype Vulnerability Scanner. Most applications indicate at least eight GPL licensed components - many of which the developers weren't aware of. A quick scan will reveal potential security, licensing, and quality problems.
To learn more about policy-oriented reports in our Sonatype Lifecycle product, watch this short demo.
We'll turn to Gartner's fourth and final recommendation next.
