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:
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:
- 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.
- 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.
- The auditor generates the report and delivers it to the organization that commissioned the audit.
- 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.
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.