Software Integrity Blog


How an open source software audit works

How an open source software audit works

Most of our readers understand that an open source software audit involves expert consultants analyzing a proprietary code base using Black Duck tools. 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 (or for some other reason). Particularly if the context is an M&A transaction, there can be 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).

Black Duck works 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 code base and its architecture. 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.

Before the audit commences, there’s a little paperwork involved, including an NDA with the third-party code owner when an acquirer hires us. Ultimately the work is agreed to with our customer in a Statement of Work that describes work to be done, code base, schedule and fixed price. We work with customers to trade off between work, schedule and cost.

The audit

In the great majority of cases, because of Black Duck’s experience and reputation, code owners are comfortable securely uploading code to Black Duck’s servers. There are a number of benefits to this approach, including minimizing costs and time, and maximizing flexibility (if, for example, the job expands and more resources are necessary). Once in a while, code owners require Black Duck to come on site, and we can work that way as well.

As soon as they have access to the code, our team begins the identification process. This is semi-automated, 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 open source components, but sometimes, due 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 this is a list of the open source components in the code base. (Actually, we often identify other third-party software as well, by digging through copyright statements in source code.) The BoM is the foundation for identifying open source risks. Only by knowing what’s in the code can you know the associated risks.

We enumerate three types of risks: legal, security and operational:

  • Legal risks are primarily the result of using a component in a way that conflicts with the terms of the open source license.
  • Security risks stem from using components that have known security vulnerabilities.
  • Operational risks come with components that are particularly out of date or inactive.

In addition to identifying the issues Black Duck provides red/yellow/green rankings for each to help with prioritization. Then we wrap the BoM and risks up into a report that we deliver to our customer via our secure reporting portal. Users can review the report in the portal or download it and, via the portal, share the report with associates.


We always offer and recommend a post audit review call during which our auditor 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, particularly counsel familiar with open source licensing. And it’s generally a good idea to have someone there familiar with the architecture of the code base 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 post-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, Black Duck will retain the original results and can thereby perform the follow-up work much more quickly and efficiently.

Final thoughts

How do our audits work? Generally very well. Having performed thousands of audits, 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.


More by this author