How an open source software audit works

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.

Pre-audit

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.

We start by assigning a project manager to work with the code owner, often a third party in an M&A transaction, to get a high-level view of the composition and complexity of the codebase and its architecture. We try to be sensitive to the pressure on them while also keeping the deal moving. In great part, the scope of work is driven by the number of files and the prevalence of open source components in the technologies used. For example, JavaScript tends to be full of open source files, whereas a typical C++ codebase contains less open source.

In the great majority of cases, because of Black Duck’s experience and reputation, code owners are comfortable securely uploading code to Black Duck 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.

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:

1. Legal risks are primarily the result of using a component in a way that conflicts with the terms and/or obligations of the open source license.
2. Security risks stem from using components that have known security vulnerabilities, usually older versions that have not been patched.
3. Operational risks come with components that are particularly out-of-date or inactive.

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.

Post-audit

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.

Final thoughts

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.