Due diligence, then, is the verify part of “trust but verify.” Going into the process on a tech deal, the software is one of the bigger unknowns. Trust though they might, sellers are reluctant to share the details of their software even during diligence with the acquirer (often a would-be competitor) should the deal fall through. Many acquirers share a reciprocal concern: If the deal falls through, they don’t want to be suspected or accused of appropriating the target’s trade secrets in the code.
But assessing the software trust triangle—the composition and licenses, the security, and the quality of the software—requires analyzing the source code, the target’s most precious asset. Acquirers have concerns about risk in these areas. Because many targets of acquisitions lack adequate controls in their development processes, there are often software issues requiring remediation. For example, the “Open Source Risk in M&A by the Numbers” white paper found that 89% of transactions included open source components with license conflicts, and 97% contained known but unpatched security vulnerabilities.
The critical role of a trusted third party is to bridge the gap. It’s important that the acquirer trust that the third party will deliver a complete analysis of the trust triangle under the tight timelines of a typical due diligence effort (weeks, not months). But even more critical is the target’s trust that the third party will protect their intellectual property and give them a fair shake in the assessment.