Avoid anaphylactic shock by auditing dependencies in software due diligence

Say you are allergic to peanuts. While out to dinner, you order a plate of spaghetti with meatballs. The server lets you know that there are no peanuts in the spaghetti with meatballs. Unfortunately, the server has no knowledge that the onions within the meatballs were fried in peanut oil. The indirect dependency on the peanut oil that was included in the meatballs by way of the fried onions left you vulnerable to an attack.

Similarly dangerous is finding big license and security problems in an acquisition’s software after the close because no one analyzed the software’s dependencies.

How software is built

Modern software is a mix of proprietary code, off-the-shelf commercial code, and open source code. Open source often includes many dependencies.

The Linux Foundation describes direct and indirect dependencies in the following way:

• A direct dependency is a package that you included in your own directory.
• An indirect dependency is a package that you are not using directly, but one that is used by one of your direct dependencies.

Mergers and acquisitions (M&As) often have extremely tight timelines, so it may seem that performing due diligence only on a seller’s source code/proprietary code is sufficient to identify all the compliance and security risks. But buyers should also be concerned about the components upon which the seller’s application depends. If components under copyleft licenses are nested in the application’s direct and indirect dependencies, the buyer is taking on the responsibility to comply with those copyleft licenses as part of the whole work. Similarly, security vulnerabilities in dependencies may expose the entire application. 

If an open source project is licensed under a permissive license such as MIT, a common belief is that there is no need for concern. However, in the audits we perform for M&A due diligence, we frequently find copyleft-licensed components within permissively licensed open source projects. This might not represent a compliance risk if the open source project is not being used for commercial purposes. However, when our customers are acquiring assets as part of an M&A transaction, they are almost always interested in using these assets for commercial purposes, and that is where the compliance risk resides.

Examples of license compliance issues from dependencies

• Ostermiller Java utilities: This is a GPL-licensed artifact that we have seen used in multiple codebases, often pulled into an application as either a direct or indirect dependency. For example, Facebook Java Library, which is MIT licensed, uses these Java utilities.
• MixItUp: This is an example of an open source library nested in a commercial license that requires a separate commercial license for commercial use. It is a high-performance JavaScript library for animated filtering, sorting, insertion, removal, and more. MixItUp is free for noncommercial, educational, and nonprofit use. In commercial projects, however, a commercial license is required. We recently found a dependency in a seller’s codebase as part of a WordPress theme that is commercially licensed.
• MinIO and Grafana: MinIO is a high-performance object storage and Grafana is a multiplatform open source analytics and interactive visualization web application. MinIO and Grafana are licensed under AGPL and were found in dependencies for Golang (GO). Even with modern languages like GO, components get pulled in through package managers that can be licensed under copyleft licenses like AGPL. Because of this, teams need to have visibility into what components are being pulled in through package managers.
• WordPress and phpMyAdmin: WordPress is an open source website creation platform and phpMyAdmin is a free software tool written in PHP. Both are licensed under GPL, so any codebases that use them may be subject to GPL obligations. When we audit codebases written in PHP, we regularly find commonly used frameworks and the dependencies that come along with them. WordPress and phpMyAdmin, for example, often show up in the direct dependency tree.
• Zlib: This is one of the most commonly used general purpose data compression libraries for embedded applications. It contains Zlib for Ada thick binding. Zlib as a whole is licensed under a permissive license; however, the subcomponent is licensed under GNU General Public License with an exception clause. Most code owners do not realize that they are shipping a codebase that might be subject to GPL obligations because Ada thick binding is a dependency of Zlib.

Examples of security vulnerabilities from dependencies

Security vulnerabilities can reside within dependencies as well. Here are some common examples.

• A06 – Outdated and Vulnerable Components: This is the sixth category listed in the OWASP Top 10. You can update the versions in your dependency tree, but you have minimal control over all the versions of the indirect dependencies being pulled in through your direct dependencies. It is extremely difficult to update all those versions if you don’t have visibility into all the indirect dependencies.
• Python Pillow: This is a friendly Python imaging library fork that is a commonly pulled in as a dependency from PyPi. Pillow is vulnerable to remote code execution (RCE). More than 6,000 Python packages have the dependency of Python Pillow.
• Minimist version 1.2.5: This is vulnerable to prototype pollution as part of its dependency. Some versions of Mocha and mkdirp were impacted because they were dependent on Minimist. Forty-nine percent of the audits we performed in 2021 as part of M&A due diligence contained the vulnerable Minimist component.

Some of the most commonly used frameworks have security vulnerabilities associated with them. We can call these frameworks out for review because we can identify the frameworks in the dependency tree. We are only able to identify specific frameworks by the dependencies that are pulled in at build. Without the dependencies, we could not identify the frameworks, and subsequently, the security vulnerabilities present in the frameworks.

• Spring framework is commonly used in Java development, and it was reported to have a high/critical RCE vulnerability.
• Laravel is a framework that we commonly find in PHP-based codebases, and it was reported to have a high/critical vulnerability.