Walt Szablowski, Founder and Executive Chairman of Eracent, cautions that there is a blind spot for software asset procurement and management teams when selecting and managing software products. It’s imperative for all application users and developers to understand what licensing requirements and potential security risks are involved in widely used open-source software (OSS). Maintaining compliance and protecting against vulnerabilities requires complete visibility and constant vigilance to ensure legal compliance, protect intellectual property, and avoid costly litigation and security breaches.

According to GitHub’s 2022 Octoverse Report, 97% of the software code used within modern applications is open source, with 90% of companies leveraging the low-cost and agile benefits of OSS. Synopsys researchers discovered that 84% of commercial and proprietary code bases have at least one known open-source vulnerability, and 48% contain high-risk vulnerabilities. Walt Szablowski, Founder and Executive Chairman of Eracent, which has provided complete visibility into its large enterprise clients’ networks for over two decades, cautions that “Many companies don’t understand the licensing structure of open-source software and are opening themselves up to hidden risks and unnecessary liabilities. Companies need to scrutinize what they are buying to mitigate the cybersecurity and financial risks when relying on open-source software.”

Software licenses are legal agreements that dictate how software can be used. Open-source licenses allow users to access, modify, and distribute source code under specified terms. In contrast, proprietary software can only be accessed and modified by the company that owns the source code, which is protected by a proprietary software license. Open-source licenses provide the legal framework protecting the rights of the software creators and users and are broadly categorized as copyleft and permissive. In a copyleft licensing model, the creator asserts their copyright while granting others the freedom to utilize, alter, and share the work. However, they must reciprocate by doing the same when incorporating it into their own projects.

Reciprocity in open-source software refers to the principle of giving back to the open-source community when benefitting from open-source projects. It is a fundamental concept in open-source development and is often associated with open-source licenses like the GNU General Public License (GPL) and the Mozilla Public License (MPL). Reciprocity emphasizes the idea that the benefits of open source should be shared with the community. It encourages collaboration, contribution, and the continued growth and improvement of open-source projects.

On the other hand, a permissive open-source license, or non-copyleft, offers the liberty to use, modify, and redistribute the work, even for creating proprietary derivative applications, with minimal constraints.

Strong copyleft licenses require that any additional, enhanced, or modified code must inherit all the original work’s license requirements, such as making the code publicly available. A GPL is the most recognized example of a strong copyleft license. In contrast, weak copyleft licenses require that only the source code of the original or modified work be made publicly available. Open-source licenses grant considerable freedoms, but rarely without conditions. Most demand attributions with a copyright and permission notice, sometimes requiring the full license text and publication of the source code. Others introduce extra terms regarding patents, trademarks, data, and privacy, complicating compliance.

Szablowski warns, “There can be a sinister side to copyleft. When a company develops and sells software they created using OSS or uses it internally, they need to credit the developer of the OSS by name. Failing to utilize OSS according to the structured terms outlined in the original copyleft license can lead to seriously damaging financial consequences. The original developer could demand that a company that spent years and millions of dollars developing its proprietary software be forced to provide the product to the public for free. There could be expensive litigation and even penalties for other organizations using the software.”

A newsworthy example of the critical nuances of OSS licensing claims features Microsoft, GitHub, and OpenAI, who are currently facing a class action lawsuit alleging copyright infringement. The lawsuit claims that their code-generating AI, Copilot, used licensed code snippets without proper attribution. The tool, trained on billions of lines of public code, converts natural language into code snippets across many programming languages, raising concerns over potential violations of open-source licensing. There have also been reports of Copilot inadvertently exposing secrets from public repositories, such as Application Programming Interface (API) keys included in its training data. The complaint filed in a California court seeks $9 billion in damages, alleging potentially millions of violations of the Digital Millennium Copyright Act (DMCA) Section 1202.

Procurement teams must carefully inspect the open-source content of commercial applications that they are considering for purchase or subscription to head off security risks at the pass. Application development teams must take the idiosyncrasies of open-source licensing into account when designing, creating, deploying, and updating programs. Companies should consider adding ongoing management and governance processes to their Software Asset Management program.

Non-compliance with open-source licenses can have serious consequences, including legal action, financial losses, project delays, and damage to a company’s reputation. To avoid these potential risks, businesses must understand and adhere to open-source license terms. Utilizing open-source software can expose businesses to liability issues, such as copyright infringement and breach of contract. Mitigating these risks requires compliance, educating development teams, and license tracking tools.

One of the often-promoted advantages of open-source software is the idea that with a large user base inspecting the code, security vulnerabilities can be detected and disseminated more rapidly. However, the reality is that most users primarily assess the software’s functionality and lack the expertise needed to pinpoint potential security issues. OSS undergoes constant updates and can eventually become outdated or even obsolete. A study conducted by Veracode examined 13 million scans across 86,000 repositories and 301,000 unique libraries, revealing that in nearly 80% of cases, developers do not update third-party libraries after incorporating them into an application. The study further noted that almost all repositories include libraries with at least one vulnerability, which can cascade into every application that uses that code.

A zero-day pertains to an unknown software, hardware, or firmware security weakness. The term “zero-day vulnerability” refers to the specific flaw, whereas a “zero-day attack” denotes an attack with zero days between when the hazard is discovered and when the first attack takes place. Malicious actors employ zero-day exploits, frequently through malware, to capitalize on these weaknesses. Typically, when a security issue is identified, it is reported to the software publisher, which can then issue a remedy. However, in cases where a malicious hacker is the first to uncover the defect, there is no pre-existing protection, underscoring the importance of early detection protocols.

In May 2021, the White House issued Executive Order 14028, “Improving the Nation’s Cybersecurity.” This order sets forth cybersecurity requirements for software publishers and developers engaging with the Federal Government. One significant provision stipulates that software developers must provide a Software Bill of Materials (SBOM). An SBOM is a comprehensive inventory of components and libraries comprising a software application. SBOMs typically include details regarding the content of a software application, encompassing open-source and proprietary codes, associated licenses, versions in use, component download locations, dependencies, and sub-dependencies. One notable advantage of SBOMs is their capacity to assist organizations in identifying potential vulnerabilities within the components constituting a software application, thereby mitigating security risks.

The best way to counter these risks is to minimize the unknown. Eracent maintains and curates the IT-Pedia® Open Source Library, which provides essential — and up-to-date — information about potential vulnerabilities within open-source components and libraries. This vulnerability data is a foundational piece for any cybersecurity program. This data is a critical input for Eracent’s ICSP Application Risk Management (ARM) module. The ARM module provides a consolidated repository, comprehensive management, and automated analysis for every SBOM that an organization has for the applications that it utilizes. In conjunction with Eracent’s ITMC Discovery™, the ARM module provides a match between known vulnerabilities and any installed software that may contain potentially vulnerable open-source components and libraries.

Szablowski explains, “If you don’t know the vulnerabilities, you can’t fix the problems. It’s about transparency that enables you to identify, quantify, and prioritize risks with a consolidated, proactive management approach using structure, automation, and heads-up reporting.”