Ignoring dependencies of a seller’s source code during an audit could lead to missed license compliance and security issues.
By: Julie Courtnay, software security consultant with Synopsys, and Shyam Sundar, software security consultant with Synopsys.
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.
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:
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.
Security vulnerabilities can reside within dependencies as well. Here are some common examples.
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.
It takes time to gather dependencies, and there isn’t much time in M&A transactions. For this reason, buyers and sellers might express concern about the timing and the level of effort needed to include dependencies in the scope of due diligence. But judging from the issues that we found in our M&A due diligence, we believe it is valuable to bring visibility to all risk that might be present in an application. Fortunately, newer languages are making the collection of dependencies easier through package managers. By knowing the commands to generate, code owners can spend less time gathering the dependencies that their source code relies on.
We find license compliance and security issues in both direct and indirect dependencies, across all languages and all application types. It’s not a free lunch, but to avoid getting sick from the peanuts, it’s best to audit both source code and the dependencies.
Julie Courtnay has supported technology customers since 2004 in industries ranging from the design and verification of semiconductors, to storage, to high-performance computing, to software due diligence. She has advised on over 400 software audits. When not supporting her customers, Julie loves to ski, hike, play tennis, and read.