close search bar

Sorry, not available in this language yet

close language selection
 

Open source issues in an M&A target’s code: How do you know?

Open source issues in an M&A target’s code: How do you know?

Until you ask, you don’t know how much open source a target has used, what components it uses, or what open source issues might be latent therein. That’s why open source questions are on the checklist of virtually every acquirer in a tech transaction. And the unfortunate reality is that even asking good questions doesn’t guarantee a good answer, because most targets simply don’t know themselves. That’s why audits are frequently a component of M&A due diligence.

However, a Black Duck study published last month, the third annual Open Source Security and Risk Analysis, can give you a good sense of what you’re likely to see, with statistics on open source used by tech targets today. The study aggregates audit data from over 1,100 codebases of companies acquired in 2017 and surfaced some compelling statistics.

Almost every codebase (96%) contained some open source. The average codebase was made up of 57% open source, comprising on average 257 different open source components. Both statistics are up considerably from the previous year’s study. No wonder it’s so difficult for companies to keep track!

96% of codebases scanned contained open source, with an average of 257 open source components in each

Use of open source per se is not a problem; in fact, most in the industry consider it a beneficial and even necessary approach to software development. The real issue is how well it’s managed and, conversely, how many components in the code may be problematic from the perspectives of license compliance and security.

Case in point, 85% of last year’s audited codebases contained some kind of license problem, usually many. The most common issue was license conflict, which occurred in 74% of codebases. This happens when the license of a component is incompatible with the way the codebase is licensed overall. A common and particularly problematic scenario is GPL-licensed code in software to be distributed under a commercial license; nearly half of all codebases had a GPL conflict. More than half the codebases contained some unlicensed code, meaning the code is available on the internet but has no associated license. Copyright law says that in the default case, you can’t use software without a license.

74% of the codebases contained components with license conflicts

Increasingly, security is becoming a focus of M&A due diligence. Seventy-eight percent of the codebases analyzed had security vulnerabilities. And not just a few; the average codebase contained 64 vulnerable components. More than half of those vulnerabilities are ranked as “high severity.” And in an indication of where the problem lies, on average these vulnerabilities have been publicly known for six years! The problem, then, is that companies are typically abysmal at tracking and updating open source in their code.

The big takeaway from the study is that buyers really need to dig into how target assets are using open source. On the other side, it’s a cautionary tale for sellers, who would do well to manage their developers’ use of open source and thereby avoid surprises and problems at due diligence time.

The report is very readable and contains a lot more details. Check it out here. You can also get more commentary about potential open source issues from a recent Black Duck webinar on the subject.

Get the 2019 OSSRA report

 
Phil Odence

Posted by

Phil Odence

Phil Odence

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.


More from Open source and software supply chain risks