Open source software audits can identify undetected issues in your codebase. Learn how our audit services can help you understand the risks during an M&A.
Most of our clients understand that an open source software audit differs from an automated scan. An audit involves expert consultants analyzing a proprietary codebase using a combination of Black Duck® commercial tools and tools we’ve developed and use internally. The deliverable is a report that identifies open source in the code as well as associated risks. If you’d like to understand our process—what comes before, during, and after—read on.
Generally, customers who come to us are either acquirers looking to have Black Duck perform an open source software audit on the code of their target, or companies wanting us to audit their own code in anticipation of being acquired. There are other use cases as well; for example, it’s becoming more common for investors, lenders, and IP insurers to require or encourage Black Duck audits.
Commonly during an M&A transaction, there is significant time pressure. So it’s critical, first thing, to scope the job, allowing all parties to quickly understand the time and costs involved. We regularly amaze customers with our responsiveness when we get called in at the last minute, but scoping early can save everyone time and money (and headaches). I hate to hear customers or their counsel say, “We didn’t want to bring you in earlier, because we weren’t sure about the deal.” Don’t worry about us—in fact, lean on us. As soon as you think it’s appropriate, we are happy to get to work even understanding that the audit might never materialize.
In the great majority of cases, because of Black Duck’s experience and reputation, code owners are comfortable securely uploading code to Synopsys servers. We don’t require code access to scope, but it’s the most common and best method, as it’s the most efficient way to do the work. Audits rarely need to be done onsite. The benefits to this approach include minimizing costs and time, and maximizing flexibility. For example, if the job expands and more resources are necessary or a transaction gets put on hold, we are limited with people onsite.
Before the audit commences, there’s a bit of paperwork required, including an NDA with the third-party code owner. Ultimately the work is agreed to with our customer in a Statement of Work that describes work to be done, codebase, schedule, and fixed price.
Open source audits continue to be our flagship offering, and we do them for almost every client. But many rely on us for a broader range of software due diligence needs, including code quality, application security, and evaluating the software development process. Each of those areas are specialized, so although clients might not perceive it, auditors have various areas of expertise, and different auditors focus on different services.
As soon as they have access to the code, expert auditors begin by identifying open source and other third-party components. This is semiautomated, meaning that identification relies on an excellent set of tools as well as the expertise of auditors. For comprehensiveness, Black Duck tools employ a variety of techniques to ferret out unknown open source. In many cases, the tools definitively identify components, but sometimes, due to limited information in the code, they just provide clues to support auditors’ detective work.
The result of this identification process is a comprehensive software Bill of Materials (SBOM). Essentially this is a list of the open source components in the codebase. We often identify other third-party software as well, by digging through copyright statements in source code. The SBOM is the foundation for identifying open source risks. Only by knowing what’s in the code can you know the associated risks.
We then enumerate three types of risks associated with open source: legal, security, and operational:
In addition to identifying the issues, audit reports provide red/yellow/green rankings for each issue to help with prioritization. We wrap the SBOM and risks into a set of reports that we deliver to our customer via a secure portal. Customers can share internally with advisors and, sometimes, with targets.
We always offer and recommend a post-audit review call during which our project manager walks through the report and answers questions about how it was generated and the results. Ideally, the call includes customer staff or advisors who can interpret the implications of the risks in light of the customer’s unique situation. It almost always makes sense to have legal counsel involved, ideally someone familiar with open source licensing. And it’s generally a good idea to have someone there familiar with the architecture of the codebase and someone who understands cyber security.
The extent and severity of the issues identified varies, but there is almost always some cleanup required. In the case of an acquisition, the closing may wait for remediation, or the parties can agree to take care of things after the close. In some scenarios, customers want to verify that all identified issues have been addressed. After remediation, we can perform a verification scan, and provide a new, presumably clean report. If the customer anticipates this, we will retain the original results and so we can perform the follow-up work much more quickly and efficiently.
How do our audits work? Generally, very well. Having performed thousands of them, we’ve refined our processes to minimize stress on all parties and to enable us to meet tight schedules. At the same time, we maintain the flexibility to meet customers’ specific needs. If there is anything you need, just let us know.
Phil is the general manager of Synopsys’s Black Duck Audit business auditing the composition, security and quality of software for companies on both sides of M&A transactions. He focuses on software due diligence best practices and the M&A market. He also works closely with the company’s law firm partners and the open source community and is a frequent speaker on open source management and M&A. Phil chairs the Linux Foundation's Software Package Data Exchange (SPDX) working group which created an ISO standard for Software Bills of Materials (SBOMs). With decades of software industry experience, Phil held senior management positions at Hammer/Empirix and High Performance Systems, a startup in computer simulation modeling. He began his career in marketing and sales with Teradyne's electronic design and test automation (EDA) software group. He’s also written a book on fly fishing. Phil has an AB and an MS in engineering from Dartmouth College.