This past March, we had the privilege of delivering our talk entitled “Dependency Management: Risk versus Crisis Management” at FOSS Backstage, a two-day conference in Berlin that focuses on all aspects of FOSS governance and open collaboration. In this blog, we’ll share the insights from the talk which focused on the legal and security challenges that arise in dependency management and why risk management planning is more crucial than crisis management.
A word on dependencies
A dependency is a piece of software another piece of software depends on to operate. Some dependencies are used directly, while others are pulled in by another dependency. Build tools in software development use build dependencies, whereas runtime dependencies are required for a software to execute.
When we deal with well-known challenges, dependencies do the heavy lifting, helping us to focus our efforts on our unique innovations and bringing them to life much faster. While this approach to software development is beneficial, it should be noted that every third-party component comes with its own dependencies, which may bring along additional dependencies. Thus, we may rely not just on our own well-known code with all of its imperfections, but also on code created by unknown third-party sources, which may or may not be sufficiently maintained.
Using dependencies comes with risks, particularly when multiple dependencies are involved. The more dependencies a software has, the greater the risk for those who use it. When it comes to dependency risk management, the most common risks are legal compliance and security risks.
License compliance risks
The most common license compliance risks are potential copyright and/or intellectual property infringements, and violations of open source licensing terms and conditions for usage and distribution.
Let’s review a hypothetical situation where an organization develops and distributes a project using open source software, without thoroughly inspecting it or identifying direct and transitive dependencies and their corresponding open source licenses. Upon releasing the project, the organization fails to disclose the necessary copyright or source code information due to a lack of awareness about their dependencies. Maybe they modify a dependency under the GNU General Public License Version 2 but don’t release the modification under the same license. In this situation, the code author and/or copyright holders may pursue legal action against the organization.
In the worst-case scenario, the organization could face litigation. If a judge rules in the plaintiff’s favor, the organization may face a broad spectrum of legal and business consequences, ranging from substantial financial penalties, project shipment suspensions, and the need to rebuild projects to remove infringing software.
Such legal consequences may indirectly result in customer support difficulties and lost revenue due to project suspension or rebuilds. Additionally, the organization’s reputation, market share, and community trust may suffer as a result.
The BusyBox litigation from 2007 to 2013 provides a real-world example of open source license violations and the resulting litigation. During this period, Software Freedom Conservancy (SFC) filed a series of copyright infringement lawsuits on behalf of the principal developers of BusyBox, citing violations of the GNU GPL 2.0.
Security risks
Security risks associated with dependencies can range from minor to catastrophic, potentially affecting millions of unsuspecting individuals.
That’s quite a dramatic statement, and unfortunately became a tragic reality for more than 145 million people in 2017 during the Equifax data breach. Equifax, a multinational consumer reporting agency, manages vast amounts of personally identifying data for US citizens.
The breach resulted in extensive media coverage, the former CEO testifying before US Congress, and filing and approval of a class action lawsuit and settlement. Equifax paid millions in fines and reportedly spent over a billion dollars on the aftermath of the data breach.
Publicly available information reveals that Equifax continued to use the Apache Struts library with a known security vulnerability, even after the library was patched to address the issue. This failure to upgrade their systems led to the exploitation of the resulting data breach.
While this horror story may cause panic, it’s crucial to adopt a safe approach when using dependencies to mitigate potential risks.
Choose your dependencies wisely
There is a wide variety of software libraries that you can use in your project to speed up development and achieve your goals. However, it’s important to consider multiple criteria when selecting dependencies.
Licensing
When choosing a dependency, it’s important to check its license, and the licenses of its direct and transitive dependencies.
Good practices to follow are making sure you know what you are using, as well as being aware of the license obligations that come with it. If there are multiple licenses, select the most suitable for your project and ecosystem, and make sure to disclose your choice. Note that some libraries have submodules that may be governed by inappropriate licenses. It’s best to remove submodules before using and distributing the library with your project.
Fit for purpose
Consider whether the dependency provides the sole functionality you need, or if it includes unnecessary complexity that could lead to bugs and a larger attack surface.
Project health
Don’t rely solely on GitHub stars, watches, forks, etc., to evaluate a project’s vitality. Check the opened issues and change requests, resolution times, release frequency, community size, active contributors, and leadership.
Code and documentation quality
Choose dependencies with well-documented design and high code quality. You may need to debug them one day.
Test coverage
Select dependencies with comprehensive test coverage and a well-maintained test suite. This increases the certainty that the project does what it’s meant to do. Poor test coverage could lead to unexpected bugs that affect multiple users.
Security
Choose dependencies with a well-established security response policy. A non-existent or weak one can expose your code to attacks once vulnerabilities are discovered.
Typically, security issues receive the same level of attention as any other project issue and are addressed as promptly. If there is a backlog of unresolved issues, it’s possible that undisclosed security vulnerabilities are also being left unattended.
Adoption
Widely adopted projects receive more attention and therefore, are more likely to have already discovered and resolved bugs. Such projects are usually safer bets than those with fewer users.
Track your dependencies
After carefully choosing your dependencies based on various criteria, it’s important to track them.
Policy
Establish an internal policy that outlines the use of open source dependencies. Open source software can be used, modified, and distributed for free under the condition that it complies with the open source license terms and conditions.
Tailor your policy to match your willingness to comply with the license’s terms and conditions. For instance, if you are not willing to comply with the terms and conditions of the GNU GPL 2.0 license, your policy should reflect that you shouldn’t be using dependencies under that license.
Review process
Your internal review processes should be designed to ensure compliance with the established policy. Scale your processes based on your needs. Start with the basic processes such as inventorying all used and distributed dependencies and performing open source license due diligence based on the established policy.
A successful review process should be performed as early as possible in the software development life cycle, be performed diligently, and continue throughout the project lifecycle.
Tooling
Introducing a tooling solution can help facilitate the review processes. There are many tools available, including proprietary and open source options. You may even develop your own.
When choosing a tool, consider its scalability to your needs, associated costs, who will use and maintain it, and how compatible it is with your pipeline management and build systems.
Update your dependencies
As your project evolves, so does its dependencies, each at their own pace.
New versions of dependencies may offer security fixes, bug fixes, or new features. Before updating, spend some time to understand the changes and evaluate how urgent it is to adopt them.
For security vulnerabilities, first determine if you are affected. If the problem is of medium or higher severity, updating with high priority is recommended. The same for critical bug-fixes. While new features can bring value to your project, they may not be that urgent in nature. Features that have no current use case are even less so.
To successfully upgrade dependencies, allocate sufficient time to adjust your code to address breaking changes and introduce new tests as needed. Don’t forget to run all your tests to make sure everything works as expected and there is no regression. Update your documentation and release notes, and then package and release your project to your users.
Be careful not to fall behind with outdated dependencies. When a dependency version is no longer supported, it’s highly recommended that you replace it with an actively supported version. If that is not possible, you need to assume maintenance and patch it in your version.
Conclusion
Using open source software is not just about getting something for free. It’s more like taking care of a puppy that you’ve adopted for free. You need to put time and effort to ensure that the puppy is happy and cared for in the same way that your software is used properly, maintained, and kept up to date.
Managing those dependencies depends on various factors such as your project, team, and usage. There is no one-size-fits-all solution. Your approach will evolve over time as you become better at identifying and mitigating risks. The challenges you face will also evolve and become more complex, but with careful management of your dependencies, you can stay ahead of the game.
Stay tuned to the Open Source Blog and follow us on Twitter for more deep dives into the world of open source contributing.
