Identifying open source in the target’s codebase is essential to M&A transactions involving software. Open source audits go far beyond what SCA can provide.
Open source is everywhere. Researchers have been tracking its growth for years, but because open source is now so pervasive, they are increasingly concerned about the security of applications built on the foundation of open source components. Organizations are also becoming more aware of the legal risks of failing to comply with the open source licenses that govern the components they use. Consequently, open source security and license compliance are a primary concern of acquirers and targets involved in tech merger and acquisition (M&A) transactions.
Organizations can track the open source they use by performing software composition analysis (SCA), an automated process that identifies third-party code used in an application. SCA discovers unpatched code, licenses, and potential security vulnerabilities associated with open source in a codebase. However, in M&A transactions involving software, stakeholders require an intense evaluation of the open source in a codebase that exceeds what an automated SCA tool can provide, and they need it fast.
Why isn’t SCA enough to evaluate open source in M&A?
Automated SCA is useful for an individual company monitoring and identifying its own use of open source components and frameworks. In a recent study, 451 Research also detailed the use case for SCA in the M&A space. As young companies bring new applications to market rapidly, they use increasingly more open source. Diligent use of automated SCA can help these companies with vulnerability tracking, patch management, and license compliance.
However, because management of open source is still relatively immature, many companies don’t practice it. Few organizations can produce a thorough, accurate list of all the open source they use and all associated security and license information.
Even companies that use an automated SCA tool might miss parts of their codebase owing to oversight or misconfiguration. Plus, not all tools have the same capabilities (such as identifying code snippets).
So in M&A transactions, the onus shifts to acquiring companies to be aware of the potential open source risks they may be inheriting along with the intellectual property in their targets’ codebases.
Why do I need an open source audit instead of an SCA tool?
An acquirer can’t simply run their own automated SCA scans on a target’s codebase. One reason is that targets aren’t likely to hand over their source code before the deal is done. Another is that evaluating and researching the results of the scan for M&A purposes requires more time and expertise than the M&A team is likely to have.
The best way to get access to the decades of experience needed to create a highly accurate and thorough bill of materials (BOM) of all the open source in a codebase, and to do so within the deal’s timeline, is to have a third party perform an open source audit.
How much open source does the typical codebase have?
According to the 2019 Open Source Security and Risk Analysis (OSSRA) report, in more than 1,200 Black Duck Audits conducted on commercial codebases last year, the average codebase was made up of 60% open source. That means that on average, more than half of each codebase we scanned comprised open source components.
It’s important to note that a key use case for Black Duck Audits is M&A due diligence, meaning that the data in the OSSRA report is an excellent indicator of trends in open source in M&A transactions.
Why are companies using so much open source?
As 451 Research states in its brief, the trend toward faster, more iterative delivery of applications is not going to abate anytime soon: “The use of open source components in those applications is no longer a novel idea. There is now a generation of developers for whom using code written by a third party, available at no-cost, is as intuitive as any other part of the development lifecycle, and is driven by the delivery demands placed on them.”
The Synopsys OSSRA report sheds light on the relative risk revealed by open source audits:
- Over 96% of the codebases scanned contained open source, with an average of 298 components per codebase.
- 68% of codebases audited last year had a license conflict, and 38% contained components with no known license.
- 60% of the codebases contained at least one open source vulnerability, with 40% having high-risk vulnerabilities.
What’s the risk of not evaluating open source in M&A?
The trend of increasing open source use creates two main concerns in an M&A scenario: First, companies must understand what and how much open source is in the software they’re acquiring to assess the potential risk to their newly acquired intellectual property. And second, they must understand this risk profile ahead of the deal to protect the ROI of their investment and plan for any required remediation cost post-deal.
Failure to understand these risks can be costly. To put it in the starkest of terms, imagine you were acquiring Equifax and did not perform open source diligence. As was highly publicized, the 2017 security breach—which compromised the personal data of more than 140 million people—was the result of an unpatched open source vulnerability in the Apache Struts framework. The breach itself has cost Equifax $1.4 billion so far, and the impact reaches far beyond the financial. Now, take one more leap with me: What if this happened in Europe under GDPR? Imagine the impact to the ROI of that acquisition.
What the OSSRA report and the 451 Research study have revealed is that these two trends are inextricably linked: The growth of open source is not slowing down anytime soon, so the stakes for M&A involving software continue to get higher. M&A professionals must understand the full risk profile of the software they are acquiring. Our new white paper Open Source Risk in M&A by the Numbers details the risks that acquirers and targets can mitigate by performing an open source audit in M&A due diligence.
*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Shandra Gemmiti. Read the original post at: https://www.synopsys.com/blogs/software-security/open-source-ma/