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.

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 (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

Open Source Audit StatisticsIn 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.

Post-Audit

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 cybersecurity.

The extent and severity of the issues identified varies, but there is almost always some “clean up” 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.

Request a Custom Code Analysis

0 Comments
Sorry we missed you! We close comments for older posts, but we still want to hear from you. Tweet @black_duck_sw to continue the discussion.
0 Comments

MORE BY THIS AUTHOR

Auditing Code Quality: A Broader Picture

| Mar 2, 2017

Black Duck is well-known for open source audits, but that is only a piece of the technology due diligence puzzle. Auditing code quality assesses other aspects of a company’s software assets and completely complements an open source audit. Both audit types dive into issues that impact the valuation

| MORE >

3 Areas of Open Source Risk: Legal, Security…Do You Know the Third?

| Dec 20, 2016

Looking back five or ten years, companies managing open source risk were squarely focused on license risk associated with complying with open source licenses. Beginning in 2014, when open source security vulnerabilities began to get names (like Heartbleed, Shellshock and Poodle), open source

| MORE >