SBN

The due diligence of a deal

Technical due diligence on the target’s SDLC is a must for acquirers in software M&A. What you don’t know about their process and tools could hurt you.

Technical due diligence on the target’s SDLC in software M&A

Before you merge with or acquire another company, there are several factors you need to consider. Among them are the target company’s finances, employees, legal situation, customer base, and technology. That last one, technology, involves not only the technology the company builds but also how they build it. As part of tech due diligence, you should evaluate the target company’s software development life cycle (SDLC) process and tools. Let’s look at how to do that.

Get the white paper: Top Considerations for Evaluating the Tech in Tech M&A

Who’s buying technology companies?

For M&A activities involving technology companies, there are two basic types of buyers:

  • Corporate, or strategic, buyers who seek to “bolt on” a target company’s software technology to their existing technology stack.
  • Private equity buyers who purchase a tech company and seek to run it (or have it managed) as an independently operated, wholly owned subsidiary, or portfolio company. It’s likely that over time, they’ll prep it for acquisition by a strategic buyer.

The type of buyer you are affects the technical due diligence methods you use to evaluate the processes and tools of the target.

View to a purchase

In a technology acquisition, a strategic buyer will typically have one or two perspectives (not mutually exclusive) on tech due diligence for process and tools:

  • If you plan to buy the entire operation and keep it intact, you should assess how the target conducts software development and with which tools.
  • If you plan to integrate the acquisition into your organization, you must become familiar with the target’s processes, which directly affect the integration and potential risks.

Where processes are lacking, you must dig deeper. For example, if the target has no process for managing open source components, it’s particularly important that you analyze code for open source licensing and security issues, according to a 451 Research report. This open source licensing and security evaluation is generally conducted with a software composition analysis (SCA) solution.

If the target has no open source management, you must analyze code for open source licensing and security issues.

Private equity acquirers, who usually keep targets intact, should make sure that the target’s development process/tools and supporting infrastructure are up to industry standards. They’ll also want to ensure that the software is secure and the IP is protected, since they have taken on the risk. Some firms enlist consultants if they lack expertise in technical due diligence.

Analyzing open source risk where there’s no process

Some developers tend to think of open source software components as free without any associated cost. So what’s the big deal about having a license? The fact is that even free, open source software requires that you have a license. If your codebase is audited during tech due diligence for M&A or other reasons, you need to be able to show you have all the rights to the open source components in your codebase, or there could be legal consequences. And this problem is more widespread than you might assume.

For example, 85% of over 1,200 commercial codebases we audited in 2018 contained components with license issues. In addition, 38% contained unlicensed components for which the seller had no rights. And being out of license compliance can have serious consequences, including these:

  • Lawsuits
  • Impact on corporate reputation (if sued for licensing, etc.)
  • Loss of IP (if license compliance requires distribution of source code)

M&A risks in process and tools

Mergers and acquisitions involve several risk assessment actions for potential targets. More and more, SCA forms an indispensable aspect of technical due diligence. Some larger companies make many acquisitions every year, so they have experience assessing these risks. They might either conduct their own SCA and due diligence or work closely with a trusted partner or consultant.

Smaller companies, normally the acquisition targets, are less likely to have experienced this risk assessment pressure. Consequently, they likely haven’t reviewed their policies, practices, or technical infrastructure closely. This is something acquiring companies must take into consideration.

Modern software built with libraries of open source code is more common than ever. So buyers must make sure their targets have been following best practices for license compliance.

Open source security is everybody’s responsibility

The use of open source components has gone mainstream. Companies ranging from large enterprises to two-person startups use open source components. As a result, developers have become faster and more productive. But this doesn’t relieve them of the responsibility to find and fix the security vulnerabilities in those open source components. That applies even to open source components that have been around “forever.” Researchers continue to find new vulnerabilities in open source components no matter how mature they are.

Therefore, developers need to keep on top of alerts and patches from all open source and third-party sources. You don’t want to be the next Equifax/Apache Struts data breach with a potential 140-million-person class action lawsuit hanging over your head. If the developers at Equifax had simply used the most up-to-date Jackson parser, they could have quickly identified their Apache Struts vulnerability.

So if you’re thinking of buying a software technology company, make sure your tech due diligence determines whether the target has built security into their SDLC. Setting up a continuous testing process to complement a continuous integration / continuous development process only makes sense. With the proper process and toolset—including software composition analysis—development teams can remediate both historic and recently published vulnerabilities more quickly, enabling them to deliver more secure, higher-quality software faster.

More top considerations for technical due diligence

To find out more about other top considerations for evaluating technology acquisitions, including the target’s products and people, download our white paper Top Considerations for Evaluating the Tech in Tech M&A.

Get the white paper


*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Phil Odence. Read the original post at: https://www.synopsys.com/blogs/software-security/technology-due-diligence/