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 keenly 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 Business Impact Brief, 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. SCA tools are most successful when integrated directly into the development workflow so dev teams can mitigate open source risk without sacrificing speed.
But depending on what SCA tool the company is using, they might miss open source lurking in the code. A dependency scan is great to pick up declared open source, but open source that was not declared in the package manager or was brought in as a partial or modified component may be completely missed. Further, open source can also make it into the code via the copy-pasting of an open source code “snippet.” While this seems like a minor addition at the time, that code is still subject to the license obligations of the component it came from and needs to be surfaced in M&A due diligence.
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 automated scan?
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 to the acquirer before the deal is done. Second, automated SCA scans produce the best results when integrated into the development workflow so the organization can monitor the build. Finally, 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 software 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 2020 Open Source Security and Risk Analysis (OSSRA) report, in more than 1,250 Black Duck Audits conducted on commercial codebases last year, the average codebase was made up of 70% open source. That means that on average, more than two-thirds 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 99% of the codebases scanned contained open source, with an average of 445 components per codebase.
- 67% of codebases audited last year had a license conflict, and 33% contained components with no known license.
- 75% of the codebases contained at least one open source vulnerability, with 49% 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 costs 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.
And the truth is, Equifax handled the remediation of the Apache Struts vulnerability far faster than the average vulnerability is remediated. For example, the Heartbleed vulnerability, which was disclosed in 2014 by members of our Finnish CyRC team, still remains a global issue.
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.
Continue Reading
Audited vs. automated: What your automated open source tool isn't seeing
The hidden business risks of technical debt in mergers and acquisitions
From diligence to integration: How software audits inform post-close M&A strategies