Most companies involved with technology M&A understand the importance of open source risks in software. Today’s software contains significant amounts of open source, on average more than 50%, according to a 2018 Synopsys study. Consequently, it has become the norm for acquirers to raise open source questions as part of technical and legal due diligence.
How to perform open source due diligence
There are several ways to assess and manage open source risk in a transaction. Here are just a few:
Ask the target
Obviously, the simplest approach to determining what open source is in a target’s IP is to ask the target. But many targets have difficulty producing a full and accurate inventory (also known as a “bill of materials” or BoM) of open source in their code. So relying on the target’s knowledge for open source due diligence can be problematic. See “Reps and warranties.”
Rely on reps and warranties
Reps and warranties are the assertions that buyers and sellers make in a purchase and sale agreement. Both parties rely on each other to provide a true account of all information. From an open source due diligence perspective, the seller represents that they’re in compliance with all open source licenses and known security risks. However, beware of knowledge qualifiers—that is, where the seller limits the reach of reps and warranties to what the relevant party “knows.” Few companies manage their developers’ use of open source effectively. Consequently, most codebases contain unknown open source components that may carry license or security risks.
Employ a third party for an open source code audit
The only way to be sure of what’s in the code is to analyze it. But few targets are willing to grant extensive code access to potential acquirers. In any case, acquirers will question the accuracy of results produced by a target. Given those reasons, acquirers often involve independent third parties, such as Black Duck by Synopsys, to do a code analysis focused on open source.
How a Black Duck Open Source Code Audit works
Black Duck tools employ a variety of techniques to ferret out unknown open source. In many cases, the tools definitively identify open source components. But sometimes, owing to limited information in the code, they just provide clues for expert auditors to chase down.
The result of this identification process is a comprehensive bill of materials (BoM), essentially a list of the open source components in the codebase. The BoM is the foundation for identifying open source risks. Open source due diligence must surface all open source–related risks in a codebase. And only by knowing what’s in the code can you know the associated risks.
Learn how to evaluate open source content in software assets for M&A due diligence.
*** This is a Security Bloggers Network syndicated blog from Software Integrity authored by Fred Bals. Read the original post at: https://www.synopsys.com/blogs/software-security/why-open-source-due-diligence-ma/