Acquirers need to ensure that the target has rights to use the third-party code incorporated into their software. The extreme misuse of software can result in lawsuits or even loss of proprietary intellectual property. Today it is typical for half or more of a target’s code to be third-party code—mostly open source. The starting point is to generate a comprehensive list of open source and other third-party code. Buyers often request this in a disclosure from the target, but few targets manage their open source well enough to provide anywhere near an accurate list. The complexity of software requires specialized tools as well as auditor expertise to create a comprehensive list.
Once the list (also known as a software bill of materials) is established, an auditor can identify associated licenses and obligations for each component. Understanding how the third-party components are implemented, auditors can suggest license conflicts and where obligations may not be met. Obligations can range from simply putting copyright information in a notice file to making source code available; and with respect to commercial code, the obligation is often to pay license fees. Although a competent auditor can give directional advice on issues, software licensing can be complex and so it is prudent to involve a knowledgeable lawyer.
In today’s climate, software must be secure. That doesn’t require a lot of explanation. Security vulnerabilities are defects in the code that can be exploited by bad actors. An acquirer’s security experts may be able to perform some level of security analysis themselves, but to examine the code for vulnerabilities will require more access, which most targets aren’t willing to provide.
A comprehensive security evaluation must first identify high-level design flaws—which account for 50% of all security vulnerabilities—and ensure security controls are designed into the architecture. Next, it must analyze the proprietary code for security bugs from the outside in via ethical hacking and from the inside out via application security testing tools. Finally, it should draw upon the bill of materials from the open source audit to evaluate known vulnerabilities in the components. Here again, most targets do not have processes to keep open source components patched with the latest security fixes.
Software quality risk may not be as acute as legal or security risks, but it’s more insidious. It’s the “gift that keeps on giving.” Low-quality software written in a nonmodular way is hard to maintain which makes it difficult to add features, fix bugs, and to patch vulnerabilities. Thus, poor quality imposes a burden that steals resources from the future by requiring non-value-added work and by reducing developer productivity to perform it.
The first step in evaluating overall software quality is to assess the quality of the design and architecture to determine whether the software is hierarchically structured and modular, and therefore scalable. It’s not unusual for the actual architecture to differ from what is on paper. As such, this evaluation needs to go beyond reviewing a diagram and get into the real code.
A great architecture can have a poor implementation, and vice versa, so it’s also important to dig into the quality of the code with specialized static analysis tools and human review. Ideally, the proprietary code is well-written and the open source components are up-to-date and supported by the community.