Role of Software Composition Analysis in M&A Due Diligence

Nowadays, it is not uncommon to encounter open source integrated into larger bodies of code. As a result, this presents a set of verification challenges both from a security and compliance perspective. These challenges emphasize the importance of software composition analysis, especially in corporate transactions where software changes hands.

The analysis is also referred to as software audit or open source due diligence. The due diligence process, in which the acquirer performs a comprehensive review of the target’s software, is now a standard part of any merger or acquisition (M&A) transaction. This blog post will delve into due diligence in M&A as well as address the most common related questions.

What is open source due diligence?

Open source due diligence is the process of performing a software composition analysis on a body of code to assess any identified risks relating to security and license compliance. This exercise is often conducted in two primary use cases. The first is complementary to ongoing software development efforts. Organizations adopting software from third-party vendors or other open source ecosystem channels deploy SCA tools and integrate them as part of their development pipeline. 

The second primary use case is corporate transactions. Virtually any technology transaction (e.g., merger, acquisition, technology investment, etc.) will involve software in some form. The open source due diligence process is now a standard part of such corporate transactions to identify any potential issues that might significantly impact the value of the software assets. Identifying such problems and resolving them is often essential before executing the transaction.

What is the output of an open source due diligence?

The output of the due diligence varies depending on the SCA service provider. However, they all include the following key components: security analysis, licensing risk analysis, and Software Bill of Materials. We briefly describe each of these components below:

Security analysis

This analysis produces a report that lists all discovered security vulnerabilities in the scanned codebase. It also includes severity classification and recommendations for possible mitigation and fixes.

Open source licensing risk analysis

This report often flags potential licensing issues related to mixing code or linking components licensed under incompatible licenses. It’s referred to as license conflict analysis.

Software Bill of Materials (SBoM)

This list of all discovered open source components includes detailed information, such as license information and associated obligations.

Some service providers offer extra add-on services, reports, and customized analyses related to dependency analysis. These non-core components of typical due diligence are negotiated as part of the service agreement and vary per service provider.

Open source due diligence process

Conducting an M&A open source due diligence often involves three parties. These include the provider of analysis service, the one requesting the analysis, and the party that owns the software to be analyzed. After the initial steps of getting a quote and executing a service agreement, the following steps describe the actual due diligence process:

  1. The provider of the SCA service is granted access to the source code via various possible methods such as a secure upload or an onsite visit.
  2. The auditors scan the target’s source code, evaluate the results – this may involve a certain level of communication with the target organization to clear up any pending questions. 
  3. The auditor generates the report and delivers it to the organization that commissioned the audit. 
  4. A call or a face-to-face meeting follows to review the results and address any open questions.

This method is standard across audit service providers since it allows the opportunity to collect multiple bids for the same audit job. Similarly, it also provides the ability to choose the best offer given your specific requirements.

What insights can you learn from due diligence exercises?

In addition to the provided output from the audit, we can gain several insights related to engineering, legal, and business practices. In the following sections, we discuss each of these insights.

Several insights learned from due diligence

Engineering insights derived from the due diligence exercise include a better understanding of: 

  • The modularity of software components
  • Integration and mode of interactions between various components or modules
  • Documentation practices 
  • Source code organization, including the separation of open source and proprietary components 

It is generally accepted that good programming practices are also legal best practices. There is a high correlation between good engineering practices and good compliance practices.

License compliance insights derived from the due diligence exercise include a better understanding of: 

  • Established policies and processes to handle open source compliance, including adequate mechanisms to satisfy open source license obligations
  • Development practices that may pose a challenge of a conflict with the acquiring company’s open source policies
  • Proprietary software assets that are at risk due to misuse of open source software licensed under vital copyleft licenses
  • Compliance risk portfolio and its alignment with the comfort zone of the acquiring company

Business insights derived from the due diligence exercise include a better understanding of: 

  • The composition of the code from a licensing perspective – i.e. the percentage of the proprietary value-add original code versus open source code – and the respective value each bring to the valuation of the company, including the importance of integration  
  • Compliance with open source licenses when comparing the actual compliance of distributed products and services with the audit findings

Tools that streamline the process

Open source due diligence is one task in a long list that must be completed in an M&A transaction. However, it is still an essential aspect, given the central role of software and potential licensing, compliance, and security risks. Although this may seem like a lengthy process, it often can be conducted quickly, especially when working with a swift SCA service provider. 

Maintaining good open source security and compliance practices enables companies to be ready for any scenario where software changes hands, from a possible acquisition, a sale, or product or service release.

Want to stay up to date with our latest news and products?

Share on linkedin
Share on twitter
Share on facebook
Share on google

Leave a comment

Your email address will not be published. Required fields are marked *