Open Source Vulnerabilities: The Newest Vector of Attack

If your software development team is like most modern efforts, you have embraced Free and Open Source Software — or FOSS as it is commonly referred to in the industry. If the team has been well led and well trained, they may have a good understanding of the potential issues FOSS creates with respect to their intellectual property and have policies and procedures in place to address those concerns. For most software development teams, FOSS has allowed them to save money and accelerate development — but now security concerns are rapidly surpassing intellectual property fears. However, if they are similar to most teams in 2022, they may be beginning to understand FOSS vulnerabilities with respect to cybersecurity and data breaches. With respect to mergers and acquisitions and related insurance coverages, leading organizations have already moved to expand FOSS diligence from traditional IP/licensing risk assessment to identifying, evaluating, exposing and remediating security vulnerabilities. In today’s environment, FOSS issues can complicate, delay or even break deals.   

As an industry, we are now being forced to recognize that FOSS components can badly undermine cybersecurity. By using FOSS, many organizations have unwittingly made themselves more vulnerable to attacks by bad actors that can have significant adverse impacts. These FOSS-based threats to system security largely came into focus in 2020 and 2021 with major news stories surrounding some of the largest examples, including the SolarWinds and Log4j exploits. These two specific instances, along with others, have disrupted major international corporations and threatened the security of nations worldwide. While these two examples have received most of the attention, they are just the tip of the iceberg when it comes to FOSS-introduced systems security compromises. Forward thinking development teams, executives and well-informed investors are rapidly coming to accept the reality that FOSS is a sword that cuts both ways and one that must be handled with care.

For all of the good, bad and ugly, FOSS is neither a new phenomenon nor is it going away any time soon. Rather, all indications are that FOSS availability and utilization will only expand. To take advantage of development efficiencies inherent in FOSS, companies need to rapidly understand and adapt to these emerging risks. There are solutions, best practices and approaches that can achieve those development efficiencies while mitigating IP and security vulnerabilities.

What is FOSS?

Free and Open Source is the overarching term used for software and content distributed as modifiable source code under non-commercial or “free” licenses. In the industry, people use the terms libraries, components or packages interchangeably when referring to FOSS. Some components are updated and well maintained with bug fixes and regular releases of security patches, but many are not. Depending on the licensing specifics, organizations that undertake the maintenance of the FOSS components they license, including fixing security holes, may be risking clear title to the intellectual property that underpins their enterprise value. The tasks accomplished by FOSS components can range greatly in scope and complexity from the smallest functional unit — say an esoteric logging or error handling routine — to much larger elements in the form of full-scale text editors, popular database and data access engines, complete operating systems and even fully functional, complex business, technical and financial applications. There are literally millions of these components available to today’s software developers. One popular development environment (Node.js) claims over 1.3 million components currently available, and another (Python) lists nearly 400,000 individually published components.

One common characteristic of FOSS software components is that they are subject to non-negotiable license terms that govern the ways a company can use, expand, enhance and (in most cases) distribute the component as part of their own software products. These licenses can range from simple, largely non-restrictive ones such as the MIT and BSD licenses to more detailed licenses such as the Apache License, Artistic License (Perl) and Eclipse Public License, which are longer and place more restrictions on distributions and notices. At the far end of the license spectrum, there are licenses referred to as “reciprocal” or “viral,” such as the GNU General Public License (often referred to as GPL), Lesser General Public License and Affero General Public License. This last group can create scenarios that could require a company to make internally developed software freely available to third parties as works in the public domain. For most software organizations, such a forced action could destroy the value of their software asset — and possibly the company.

When it comes to protecting intellectual property rights, license details need to be carefully considered and actively managed. When securing an overall system, understanding the FOSS-introduced vectors of attack are increasingly critical.

Security Exploits: The New Risk Vector

As the Solarwinds, Log4j and other high-profile attacks have shown us, significant known and unknown security vulnerabilities are lurking in many of these FOSS components. The information technology industry has long focused on threats from outside the organization and responded with increasingly sophisticated perimeter and zone-based security deployments to detect attacks and “keep bad guys out.” In the case of these FOSS-based attacks, the threat originates inside the software itself, allowing attacks from what is often the inner most security zones. How did these security holes and exploits penetrate the software? They were inadvertently placed there by the company’s own development team through the way in which they use and manage FOSS.

Companies that have FOSS policies and procedures are, for the most part, focused on the threats to IP ownership and are caught unaware of the more immediate and sinister security issues that FOSS can introduce.

Threat Response

Whether a company is deeply involved in software development, exploring acquisition of a technology company or preparing for financing rounds or an eventual sale and the related diligence process, every technology and executive team should be revisiting their approach to FOSS and how they are addressing these rapidly emerging FOSS risks and attack vectors. Steps for consideration include:

• Develop Proper FOSS Policies: Policies and procedures need to be updated to address both the ever-present IP risk and the newly emerging security threats. If a company does not have strong FOSS policies and procedures in place, now is the time.
• Raise Awareness and Retrain: Development staffs have likely become comfortable with their FOSS components and the internal selection and vetting process. Those understandings and practices need to be updated in light of these security threats and kept top-of-mind as part of the overall development practices.
• Vet Components for Exploits and Patch: Confirm your team has a viable process in place to determine which FOSS components introduce vulnerabilities and actively monitor for identified exploits and potential patches. That said, most modern FOSS components incorporate other FOSS components. This nesting of components can go four, five, six or more layers deep and greatly complicate the identification of FOSS-introduced vulnerability. We will discuss this complexity more fully in an upcoming article in this series.
• Replace or Fix Problematic FOSS Components: While few commercial software organizations want to be in the FOSS maintenance business, certainly none of them want to explain a service impacting outage and/or data breach to customers, vendors, regulatory authorities or investors.

Bottom line: a proper threat assessment and response program needs to be a living and fully integrated aspect of all serious development organizations’ approach to the software development life cycle.

This article is the first in a series of articles and webinars coauthored by BostonCIO and Faegre Drinker that will explore both the intellectual property aspects of incorporating and leveraging FOSS and the technical vulnerability and security breaching potential of incorporating and managing FOSS. We will attempt to provide both background and education on the issues and best practices for the investment banking, private equity and investor communities as well as those in leadership positions in software development and support organizations.  

To receive future alerts on this topic, as well as information about upcoming webinars, please visit the Faegre Drinker Subscription Center to sign up for emails regarding intellectual property topics.

About the Authors:

Richard Cohen is Managing Partner of BostonCIO. BostonCIO works closely with end-user companies and all levels of the investor community. Leveraging a staff of deeply experienced technology practitioners, BostonCIO delivers development and architectural assistance, remediation services, Shared-Basis CIO™ and Shared-Basis CTO™ engagements, pre-diligence on the sell side and traditional buy-side technology diligence for private equity firms and family funds across the US.

Ira Kalina is a Technology Transactions partner in the Chicago office of Faegre Drinker. His practice focuses on information technology transactions, developing and leveraging technology and investment, and mergers and acquisitions in and of technology companies. Ira and his team have worked extensively with clients to assess and address FOSS licensing issues.