Black Duck Audits: Taking a Comprehensive Approach to Software Audits in Merger and Acquisition TransactionsAuditing proprietary code, third-party code, open source, and web services for license, code quality, and security risks

| synopsys.com | 2

Table of contents

Executive overview .............................................................................................................. 1

Understanding open source and third-party software in due diligence ........................... 2

Open source license risk ....................................................................................................................................... 2

Open source security risk ..................................................................................................................................... 3

Know your code through a software Bill of Materials ..................................................................................... 3

Third-party software and web services.............................................................................................................. 4

Assessing risk in proprietary code ..................................................................................... 4

Security risk in proprietary software ................................................................................................................... 4

Security controls and processes ......................................................................................................................... 4

Vulnerability assessment on proprietary code ................................................................................................. 5

Penetration testing ................................................................................................................................................. 5

Assessing quality in software ............................................................................................ 6

Assessing code quality ........................................................................................................................................ 6

Assessing design quality ...................................................................................................................................... 6

Assessing process quality .................................................................................................................................... 7

Conclusion ........................................................................................................................... 7

| synopsys.com | 1

Executive overviewWhen software is a significant part of an M&A deal, acquirers need to know what’s in the target’s codebase. Understanding potential software security and quality flaws as well as possible issues linked to open source code protects both buyers and sellers from surprises that could impact the value of the deal. The software audit process—a comprehensive review of the target’s software—should be a standard part of any M&A transaction in which software is an important part.

Software issues can potentially undermine the value of an M&A transaction by:

Although merger and acquisition (M&A) transactions are the most common impetus for a software audit, audits can be useful in other scenarios as well. For example, your organization might want to audit an application in preparation for a major release, in order to identify problems such as an unwanted license obligation. A customer might require a software inventory (a Bill of Materials or BOM) as part of its procurement process. Or a potential partner could request a third-party-reviewed BOM before finalizing an agreement.

Synopsys Black Duck® Audit Services provide the fast, thorough, expert audits of code needed for comprehensive software due diligence. Audit services combine the power of world-class analysis tools with human expertise to evaluate open source license compliance and security risk as well as third-party and proprietary software quality and security risks. And because both the target and the acquiring organization can trust Synopsys to safeguard the code, negotiations are smooth.

Black Ducks audits include:

• Open source and third-party software audits: This includes an analysis of the codebase to create a complete open source software Bill of Materials, which identifies license conflicts and obligations, known security vulnerabilities, and potential risk introduced via third-party web service API integrations.

• Application security audits: This includes penetration testing, static analysis, and design analysis to assess security robustness, uncover potential security weaknesses, and evaluate the overall design for missing security controls.

• Software quality audits: This assesses software quality across three dimensions: architectural design, code quality, and the processes used to develop the code.

Whether you’re the buyer or the seller in an M&A transaction (or need comprehensive insight into your code for other purposes), a software audit can help you identify and resolve problems before they become major security, licensing, or software quality issues.

Compromising proprietary intellectual

property

Putting sensitive data and systems

at risk

Impeding integration operations

Increasing remediation costs

Lengthening deal and integration

timelines

| synopsys.com | 2

Understanding open source and third-party software in due diligenceVery little of today’s software is 100% custom-built. In fact, virtually every one of the codebases Synopsys Black Duck Audit Services examines contains open source. A full 75% of the code in the proprietary codebases audited in 2020 was, in fact, open source. And 65% of those audited codebases exposed their owners to potential legal problems because of open source license conflicts with the software’s overall license.

Open source license riskOpen source software is no different from any other software in that copyright law dictates that its use is governed by a license. Even the friendliest open source licenses include obligations in return for the software’s use, so in addition to identifying conflicts, buyers need to make sure sellers are in compliance with all licenses.

Potential license risk arises when a codebase contains components whose licenses appear to conflict with the overall license of the codebase. The most common example of this is open source code under the GNU General Public License v2.0 (GPLv2), which often creates a conflict when compiled into a distributed piece of commercial software. But the same code isn’t a problem in software considered software as a service (SaaS). The obligations of the GPL are triggered only on distribution of the associated software, and the GPL doesn’t consider SaaS code to be “distributed.” This isn’t to imply that SaaS software is immune from license conflicts; some licenses are problematic for SaaS as well.

Sometimes an open source component has a so-called “custom license” in which the developer used their own licensing language for the component or added language to a standard license. Such license additions are often well-intentioned but can raise concerns, especially in M&A transactions with lawyers who need to interpret the impact and risks.

Even if a third-party component doesn’t have a license, in the U.S. and many other jurisdictions, creative work is placed under exclusive copyright by default—and that includes software. Unless a license specifies otherwise (or the copyright holders grant permission), no other party can legally use, copy, distribute, or modify that work without incurring the risk of litigation. Organizations that use unlicensed code are violating copyright law and thus exposed. Qualified attorneys can help assess the risk.

“Open source issues in proprietary code can be very damaging to the value of the software franchise from a license compliance perspective. In fact, we’ve seen with some buyers that if there’s an open source issue, they will not acquire the company at any price.”

–Technology-focused investment bank

| synopsys.com | 3

Open source security riskOpen source risk is not limited to license risk. Of the code audited by Black Duck Audit Services in 2020, 84% contained open source with vulnerabilities that could compromise the software through an attack or data breach. And 91% of those codebases contained open source components that either were more than four years out of date or had no development activity in the past two years, exposing those components to a higher risk of failure.

All software, whether commercial, custom-built, or open source, will have flaws or weaknesses that make it vulnerable to attack and exploit. Unpatched software vulnerabilities are one of the biggest cyberthreats organizations face, and unpatched open source components are a large contributor to that aspect of security exposure. An alarming number of companies using open source components don’t apply the patches they need in a timely fashion, opening their applications to potential exploits.

Open source security vulnerabilities may not be deal-breaking, but understanding the volume and criticality of the vulnerabilities in the code is important in evaluating their impact to integration timelines. Vulnerabilities, particularly the critical ones, need to be addressed to prevent a potential breach that could severely impact the ROI on the deal. And time spent remediating is time not spent on integration or innovation. Understanding this upfront allows buyers to plan for resources to get the software into a secure state and negotiate holdbacks to cover the risks.

Know your code through a software Bill of MaterialsIn the November 2019 Gartner research paper “Technology Insight for Software Composition Analysis,” analyst Dale Gardner notes that “comprehensive visibility into the open source and commercial components and frameworks used in an application or service must be considered a mandatory requirement.” Gardner goes on to recommend that organizations “continuously build a detailed software Bill of Materials (BOM) for each application providing full visibility into components.”1

The concept of a software BOM derives from manufacturing, where the classic Bill of Materials is an inventory detailing all the items included in a product. When a defective part is discovered, an auto manufacturer, for example, knows precisely which vehicles are affected and can begin the process of repair or replacement. Similarly, an accurate, up-to-date software BOM that includes an inventory of open source components is necessary for organizations to ensure their code is high quality, compliant, and secure. And as in manufacturing, a BOM of open source components allows vulnerable components to be identified quickly and remediation efforts prioritized appropriately.

Since most companies don’t effectively follow Gardner’s advice, Black Duck audits provide a comprehensive BOM of the open source and third-party components in the audited codebase. The BOM includes all open source components as well as the versions used, the download locations for each project and all dependencies, the libraries the code calls to, and the libraries those dependencies link to.

Black Duck Audits can also drill further down into the codebase to provide a detailed view of open source risks, as well as identifying the external web services used by an application.

By performing software audits periodically, even businesses that don’t have other good controls in place can maintain an accurate, up-to-date software inventory listing all license obligations as well as potential code quality and security issues in their code.

An accurate, up-to-date software BOM that includes an inventory of open source components is necessary

for organizations to ensure their code is high quality, compliant, and secure.

| synopsys.com | 4

Third-party software and web servicesIt’s standard practice for developers to leverage third-party software and web services in addition to the open source code in their applications. In general terms, third-party software is code from an entity other than the organization’s development team. Most companies differentiate third-party software from open source because the third-party component was purchased or licensed for use. For example, many businesses deliver online customer engagement through commercial third-party chat software integrated within the business’ overall web application.

A web service is a resource made available over the internet through an API, an interface used by software to interact with other software. Like open source, calls to web services made via APIs are often not formally documented within the software incorporating them.

Calls to not-necessarily-reputable web services can expose data to hackers in search of sensitive information, especially when that information is not encrypted. Many web services collect and store personally identifiable information, potentially putting companies using those services at risk of inadvertently violating regulations such as GDPR and Safe Harbor.

Obviously, third-party software is licensed. A company is subject to various licensing terms and conditions for each third-party application it uses, with some licenses potentially in conflict with others or with the overall license of the incorporating software.

Analogously, the use of web services is governed by their respective terms of service. These terms can change frequently and without notice. Usually, implicit in the end user agreement is that use of the web service equals acceptance of the terms of service, even when those terms change. The terms might limit, for example, the maximum number of queries per day, which could impose a hard ceiling on use of the software. Not every web service is reliable; performance or availability issues can severely impact applications relying on those services.

Companies by and large have no tracking mechanisms that could produce a comprehensive list of the web services they rely on, and that can leave an acquirer unaware of associated risks. Including this list as part of the overall software Bill of Materials not only allows an acquirer to properly assess risk, but also provides a more comprehensive inventory to reference.

Assessing risk in proprietary codeSecurity risk in proprietary software

An important factor in M&A activities is understanding the target company’s cyber security tools and practices, and its overall security posture. A report from (ISC)2 noted that 77% of 250 survey respondents made recommendations on whether to proceed with an M&A deal based on the strength of the target company’s cyber security program. Nearly half (49%) indicated that they had witnessed an M&A agreement fall through as a result of an unrevealed data breach.2

In the Gartner research paper “Cybersecurity Is Critical to the M&A Due Diligence Process,” analyst Sam Olyaei notes, “Today, security is a boardroom issue, and the implications associated with it can seriously

diminish the value of a future organization, especially with regard to sensitive data and intellectual property.”3

Bad actors can take advantage of organizations in the midst of a merger, banking on a lack of discipline during integration activities and potential gaps in policies that expose security holes. And given that M&A deals can raise the exposure and profile of the acquirer, they can lead to a drastic change in its risk exposure. Private equity customers have noted that it’s uncanny how consistently attacks ramp up on newly added portfolio companies.

There are many aspects of application security for an acquirer to dig into during the due diligence process, but three in particular warrant special attention.

Security controls and processesAn assessment of the security controls and processes in place will help the acquiring company understand the current maturity of security at the target company. This assessment examines issues such as whether there are controls in place for potential weaknesses in password storage, identity and access management, and cryptography. That can be a good first step to providing acquirers with a high-level look into how the target company stacks up against their own internal practices, and help determine what level of training and process development may need to take place during an integration. It can also reveal any

| synopsys.com | 5

misconfigured, weak, misused, or missing security controls that could expose the company to increased risk, or at a minimum, identify process changes that need to be planned for during an integration.

Beyond the roadmap to fix any issues uncovered, the assessment can also give the acquiring company a good idea of the discipline and maturity of the target company. This can be a key indicator of other areas of strength or weakness in both leadership and personnel, as well as overall software quality and security robustness.

Vulnerability assessment on proprietary codeJust as open source code needs to be assessed for known security vulnerabilities, proprietary code also must be assessed to determine what vulnerabilities exist in it. A static analysis of the source code will expose critical software security vulnerabilities such as SQL injection, cross-site scripting, and the rest of the OWASP Top 10. If these vulnerabilities exist in the code, it’s subject to breach and requires a remediation plan.

An audit of the proprietary code requires access to source code for the most accurate picture of risk. A target company is unlikely to provide a potential acquirer this level of access to their intellectual property before the close, so a trusted third party should perform this analysis. The benefits of this analysis include a complete understanding of the resources required to remediate vulnerabilities, and better insight into the maturity, discipline, and security checks and balances that are in place at the target company.

Penetration testingAnalyzing a target company’s source code, controls, and processes is still only part of the process. An acquirer should also verify the robustness of software security from the outside, while the software is in its running state. Penetration testing—also known as ethical hacking—enables the acquirer to find any security holes before a bad actor can exploit them.

Acquirers can leverage expert ethical hackers to perform this test or request that the target company produce their own recent penetration test report. This will give the acquirer insight into how secure the software is should a hacker try to exploit it, as well as provide insight into what may need to be fixed during the integration.

Savvy sellers might provide the results of a previous penetration test. That should provide some reassurance, but buyers should verify that it’s current and that it was performed by a reputable third party. It’s also best if the test is performed on a test system rather than the production environment. Third parties tend to “go easy” on production systems for fear of bringing them down and harming the business. On test systems, testers can be much more aggressive in identifying vulnerabilities.

| synopsys.com | 6

Assessing quality in softwareIt’s important to understand the overall quality of the target software before closing the deal. With poorly designed software, the cost of fixes and maintenance can be significant and seriously degrade ROI.

Understanding a software system’s design and overall health allows acquirers to:

• Confirm the assumptions that support the deal

• Gather information to plan the integration between the companies’ software stacks

• Identify risks that may accompany the acquired software

Poorly designed or architected software can result in the acquirer potentially taking on hard-to-maintain code, and months to years of technical debt that it may never get out from underneath. Teams can end up with a brittle codebase full of interdependencies in which one bug can create a ripple effect of breaks throughout the software. Such messy code can often lead teams to increase the technical debt, because refactoring to truly fix the underlying complexity issues can be too big of an undertaking. Metaphorically, they are too busy fighting alligators to drain the swamp. To avoid such a swamp, it’s important to assess software though three lenses: code quality, design quality, and process quality.

Assessing code quality Analyzing the quality of the software requires inspecting the source code itself. Understanding if the code is buggy, poorly written, full of technical debt, duplication, or overly complex is vital for the acquirer.

An understanding of the amount of technical debt will tell the acquirer how much time will need to be spent fixing issues rather than driving innovation. Code that’s overly complex or over-engineered will be difficult to integrate with an acquirer’s current portfolio. A code quality assessment can also shed light on how much code duplication exists. Code duplication can result in severely decreased productivity and future development. This is particularly true if code changes need to be implemented in multiple places, which increases the chances of introducing more bugs as changes permeate through a codebase.

A third party assessing the source code for open source vulnerabilities and/or software vulnerabilities in the proprietary code should also have the capability to analyze code quality, so the target doesn’t have to share its code with multiple parties.

Assessing design qualitySoftware design is key to preventing software complexity. A healthy architecture is layered and modular, with a hierarchy that makes it easy to both maintain and scale. Software architects create a well-structured plan for the foundation of an application, but as developers face tight deadlines, best practices like code reviews and automated testing can get skipped and they might stray from the intended architecture. This lack of testing and consistency can lead to codebases that are patched together and quickly become brittle.

When cyclicality and interdependent pieces of code are introduced, they create persistent maintenance problems in the codebase. The more cyclical dependencies a codebase contains, the higher the chances are that defects will be introduced as developers work on it. Worse, this typically happens without companies realizing it or understanding the extent. All that’s visible is the symptoms—slipped schedules and decreased developer productivity.

| synopsys.com | 7

Most software due diligence involves an architectural review, which generally boils down to the CTO walking through the theoretical, one-time architectural diagram. That’s useful, but it doesn’t shed light on the reality of how the code is currently structured. A deep dive design audit of the source code is required to gauge whether the code is maintainable or a hairball.

Assessing process qualityMost acquisitions include due diligence on the software development process and team. VPs of engineering, architects, and CTOs talk to their counterparts at the target company. Private equity firms tap their networks for people with relevant experience to serve in this role. This kind of evaluation is absolutely critical, especially when there will be post-close integration. These assessments tend to be informal and may include reviews of documented processes, tools, and development philosophies.

The informality of these reviews often mean a formal audit is required to complete the picture. Generally, there is correlation between the practices for producing software and the software produced. But it’s not unusual for an otherwise well-functioning development team to be hamstrung by legacy code. Acquirers need to understand both the potential for future innovation and all the issues in the current codebase that may detract from it.

ConclusionIf the software assets are a significant part of the valuation of a target company, having a third party perform a comprehensive software audit is vital. All software has issues, and it’s critical for both sellers and buyers to have a clear picture of what issues need to be addressed before the deal is closed. Sellers as well as buyers should be working to understand, and to whatever extent possible, clean up issues before a transaction is even contemplated.

When software is a significant part of an M&A deal, acquirers need to be aware of potential legal risks, primarily around license conflicts; security risks involving vulnerabilities in the code that could be exploited; risks from outdated or legacy code; risks in code quality and design quality that can significantly impact future innovation; and risks from third-party code and external web services that may be used by the application.

Buyers need an audit partner that can provide fast, trusted, and comprehensive software audits to mitigate these risks. What’s in the code matters when M&A transactions are in motion. Undiscovered open source in applications can lead to costly license violations. These, along with security flaws in proprietary, open source, and other third-party software, and large amounts of technical debt as a result of poorly designed code, can have a significant negative impact on the value of software assets.

Black Duck software audits provide the information your firm needs to quickly assess a broad range of software risks in your acquisition target’s software. Get a complete picture of open source license obligations, application security, and code quality risks, so you can make informed decisions with confidence. For more information and a free audit consultation call +1 781.425.4444 or contact Synopsys Black Duck Audit Services today.

1 Gartner, Dale Gardner, Technology Insight for Software Composition Analysis, Nov. 1, 2019.2 (ISC)2, Cybersecurity Assessments in Mergers and Acquisitions: The ROI of Sound Cybersecurity Programs, 2019.3 Gartner, Sam Olyaei, Cybersecurity Is Critical to the M&A Due Diligence Process, April 30, 2018.

“We go to experts like Synopsys Black Duck Audits to verify that there are no issues within the software asset. And that’s the value of Black Duck—at day’s end we have assurance that there’s no red flags or potential issues, if there are issues to have them brought out before the deal is completed.”

–Private equity firm

Synopsys helps development teams build secure, high-quality software, minimizing risks while maximizing speed and productivity. Synopsys, a recognized leader in application security, provides static analysis, software composition analysis, and dynamic analysis solutions that enable teams to quickly find and fix vulnerabilities and defects in proprietary code, open source components, and application behavior. With a combination of industry-leading tools, services, and expertise, only Synopsys helps organizations optimize security and quality in DevSecOps and throughout the software development life cycle.

For more information, go to www.synopsys.com/software.

Synopsys, Inc.185 Berry Street, Suite 6500San Francisco, CA 94107 USA

Contact us:U.S. Sales: 800.873.8193International Sales: +1 415.321.5237Email: sig-info@synopsys.com

©2021 Synopsys, Inc. All rights reserved. Synopsys is a trademark of Synopsys, Inc. in the United States and other countries. A list of Synopsys trademarks is available at www.synopsys.com/copyright.html . All other names mentioned herein are trademarks or registered trademarks of their respective owners. April 2021

The Synopsys difference

| synopsys.com