How To Prepare Your Open Source Software For a Successful Due Diligence
Table of Contents
So, there’s an M&A on the horizon? Congratulations! If you reached this point, then, you probably did everything right up until this moment. Now, you are about to face a new challenge – DUE DILIGENCE.
When a merger and acquisition process is happening, the acquiring team’s first goal is to assess and understand the value of the acquired company. This is achieved by a full and thorough investigation of the company’s financials, technology, litigations, sales, and all other relevant pieces of information. This investigation procedure is the due diligence process. Due diligence is done to ensure that the acquiring team knows everything there is to know before signing the contract.
Remember that coffee is for closers
Your purpose as a seller is to close – and close quickly!
Typically 20% of global M&A deals are withdrawn or terminated and percentages increase in smaller acquisitions. The consequences of coming unprepared might impact the confidence of the acquiring team in the company’s worth; furthermore, failed transactions often have lasting consequences on the ‘almost acquired’ company image. Withdrawn deals in 2014 reached $430B, which is the highest number since 2008.
It is no secret that time can be a major deal-breaker, so your #1 goal should be to prepare in advance in order to reduce due diligence duration.
Successful M&A starts with great due diligence reports
The due-diligence process is a significant step in building the trust between the two parties involved in the M&A.
And software due diligence is a crucial part of each software company’s due diligence process and it is usually the longest process. Implications can occur in every piece of code, so companies are asked to open their code inventory reports, elaborate on the development and deployment environments, third-party libraries, patch tools, and licenses.
The main goals of the software due diligence are to assess the value of the product and know if there are any red flags. There are 2 types of red flags – correctable ones and those that cannot be corrected. A correctable red flag is something like lack of documentation that you can fix. An uncorrectable red flag (which typically means walk away) can be like that of violating some third-party intellectual property.
Software due diligence is a bit like having a home inspection done when purchasing a house. Some problems are more serious than the others. For example, if you find out that there is mold or asbestos in the basement — you will be forced to reconsider.
So how should you prepare your software for a quick and successful open source audit with no red flags?
Being proactive is the key
Being proactive is critical as it can significantly reduce the due diligence duration. First, you have to create accurate and up-to-date inventory list of your software. Almost every commercial software product today consists of proprietary code, third-party libraries and open source components.
Start by organizing your code in a systematic top-down structure to identify all the proprietary code and open source components as each group will have similar compliance characteristics. And then prepare accurate and updated software Build of Material (BOM) for each group separately.
Brace yourself for handling open source – you might be using more of it than you estimate
It is no surprise that everyone wants to leverage open source. But open source comes with responsibility — like licenses to track, security vulnerabilities to manage, and updates to make. This puts open source reporting on the center stage during M&As. Acquiring companies are worried to inherit known open source issues, like losing their proprietary rights, breaking licensing terms, security risks, and other patent implications. Only 27% of companies have a formal open source policy to approve new components that are added to their software.
Remember that unmanaged use of open source can not only delay processes, it can also reduce the value or lose the entire deal.
3-step open source due diligence checklist – Here’s how to prepare
Step #1 – Create an open source inventory list
This is the most crucial step since without knowing what components you use, you cannot know what open source licenses you are required to obey, if any security vulnerability affects your product and if you should consider updating your libraries with newly released versions.
You need to identify and list out all the open source components that you use, including all dependencies. With this exercise, you will be able to identify the relevant licenses, security vulnerability and quality issues relevant to your products.
There are 2 methods you could use for this step:
The manual do-it-yourself method
The manual Do-It-Yourself method does not work great for a due diligence process — at least it didn’t work for us!
In the manual method, you ask your developers to keep a spreadsheet of all open source components and to update it every time they add or remove an open source component, but in all the cases that we have looked at, we have identified significant gaps between what was documented and the reality. Read why manually tracking open source components is so error prone.
The automated method
You can either scan your code or use a solution like Mend to automatically discover all your open source components within minutes by integrating into your build tools.
Step #2 – List all the identified open source licenses and check compliance
Once you’ve identified all the open source components that you’re using, you are required to identify all the licenses that your components have, and their dependencies. At this point, you’ll have to carefully check what is it that each license requires you to do and whether or not your company meets these requirements.
In a due diligence process, the acquiring team would like to close a deal with a clean slate, and, of course, without purchasing any legal implications. Therefore, the acquiring team will delay on the software licenses list and will check your company compliance to each one of the open source licenses you are obligated to.
Why care for open source licenses so much – isn’t open source free, right?
Open source doesn’t cost, but you may have to pay. So it’s free but not really free. There is a big misconception about open source. It is believed to be free in the sense that it has no strings attached, but it is actually only free of charge (free beer vs. free speech). In fact, open source components are, by law, commercial items. They are indeed free to use, but they come with a license which you have to comply with to avoid legal and business risks.
There are two main types of open source licenses: permissive and copyleft. Permissive open source licenses have minimal requirements regarding how it could be redistributed. Copyleft licenses, like the GNU GPL, are a different story.
Just like copyright is a law that restricts the right to use creative works without the permission of the author. When an author releases a program under a copyleft license, he makes a claim on the copyright of the work and issues a statement that other people have the right to use as long as the reciprocity obligation is maintained.
This means that any software that is written based on any component, which is copyleft licensed, must be released as open source. The result is that such software is required to release its full source code and all of the rights to modify and distribute the entire code. This might substantially reduce your company’s value in the eyes of the acquiring company, as it as has severe implications on your ability to protect your intellectual property.
Step #3 – Identify vulnerable and outdated components
Security vulnerabilities might exist in your software without you even being aware. Uncovering these issues during an M&A process can damage your process, as security vulnerabilities can be exploited by malware or hackers. Monitoring and revealing security vulnerabilities require substantial time and efforts, and its inheritance increases the risk to the acquiring team.
Try to provide accurate data with minimal efforts.
Within the due diligence process, you must not rest on laurels; usually, when an offer is made, there is a short window of time to complete the process successfully, and your goal is to provide accurate data. Fast. With minimal effort.
When both the company and the acquiring team are fully aware of the licenses used and existence of security and quality issues, they can proceed with the deal quickly and efficiently; therefore, prior preparation for due-diligence is highly crucial, as it will save a lot of valuable time (and headaches).
Once you have prepared your open source inventory list and verified compliance with your open source licenses — your next step is to see if you are exposed to any known security vulnerabilities due to your open source components.
How to identify open source security vulnerabilities?
The NIST database maintains a record of all the reported open source security. You need to compare your open source inventory list with NIST repository and check if any of the reported vulnerabilities apply to your product.
Manually tracking all CVEs is almost impossible as thousands of security vulnerabilities get published every month in the NIST database. Finding out those that affect the specific versions of the specific open source components you use can be extremely laborious and the output will surely be error-prone.
As with creating inventory list, most companies chose to automate this process before or during a due diligence process due to its great importance. The same solutions, of scanning your software or integrating Mend to your build process, apply here as well. They scan the NIST database and immediately alert you when a match is found.
The good news is that open source communities are often quick to fix vulnerabilities and bugs, so most chances are a new patch or version exists that can fix a reported issue. This is why Mend alerts you if there’s a new version or patch that can remediate a security issue.
No time to prepare for the upcoming M&A?
Mend.io is the only solution in the market that can help you automatically produce 100% accurate and comprehensive due diligence reports. Our solution can integrate with your build tool/server (we support all popular programming languages and build tools) and auto-discover all your open source components within minutes. It later pulls all the relevant information about your libraries and builds automatic due diligence reports. Our reports cover all open source related topics right from licenses to security and quality.
Start your demo to see if you have any red flags in your open source components and ensure you are prepared for your upcoming M&A.
