close search bar

Sorry, not available in this language yet

close language selection
 

Software due diligence: The home inspection of tech M&A

Similar to a home inspection, M&A software due diligence helps organizations assess the risk of an investment.

software due diligence | Synopsys

When a company buys another company, the due diligence process is analogous to a home inspection during a real estate transaction. A buyer sees only so much when they tour a home—enough to know they like it and to assess the value, but not enough identify hidden problems that might devalue the property. An in-depth assessment requires time and expertise.

Things to consider during software due diligence

Similarly, a company acquiring another starts with a fairly good idea about the target’s value and strategic fit before they agree on a price and a timeline for the deal. But when they sign a Letter of Intent, they reserve the right to dig deeper via a process called due diligence. The acquirer then has several weeks to request information, ask questions, and perform analyses to allow them to:

  • Confirm their current understanding of the target’s business
  • Plan for integration
  • Uncover any surprises that could impact the deal or their desire to go ahead
    (It’s a nice-looking house, but the foundation is crumbling and it’s about to collapse)

This kind of analysis covers all aspects of a business. Acquirers will dig into financials, HR records, legal documents, customer complaints, marketing plans—everything, including the software technology. This is particularly relevant for deals in which software is a substantial part of the value. Inquiries about the technology will range from a high-level look at product strategy and roadmap to the people and processes, and extend down to the code itself. The breadth of inquiry spans quality, security, and legal issues.

As with any aspect of due diligence, much information is gleaned through Q&As and documents as well as discussions. A meeting between respective CISOs might start with walk through of the target’s AppSec program at a high level. A disclosure request might include documented processes on open source use, handling vulnerabilities, building in security, and software architecture.

When do software audits come into play?

Where the rubber meets the road, though, is in the code. That’s where an audit comes in. It will delve deeply into all aspects of the code and focus on open source, application security, architecture, quality, and processes. This kind analysis is well-suited to a trusted third party because targets will not share their code with a potential acquirer. The exhaustive analysis Synopsys performs also requires skills that acquirers may not possess, much like a home buyer relies on the expertise of the inspector to spot issues that would escape a typical homeowner (and require willingness to crawl into the deepest corners of the attic). Applying such expertise is what distinguishes an audit from a mere automated scan.

Once alerted to security, quality, and legal issues in the code, a buyer can protect themselves in the deal and plan to address them going forward. Rarely, though occasionally, code issues can kill a deal. However, they certainly impact planning, and extreme issues can affect deal valuation, timing, or terms. Newly discovered vulnerabilities or open source license compliance issues may need to be remediated before close. A revealed architecture hairball may reduce the price to cover refactoring costs. Or buyers may hold back some money as insurance against a potential licensing lawsuit based on a discovered GPL-licensed component.

Tech acquirers rely on Black Duck® software audits to keep their technical houses in order, ensuring they are making wise M&A investments that pay off in the long run.

Learn more about Black Duck Audit Services

 
Phil Odence

Posted by

Phil Odence

Phil Odence

Phil is General Manager, Black Duck On-Demand. He works closely with Black Duck’s law firm partners and the open source community. A frequent speaker at industry events, Phil chairs the Linux Foundation's Software Package Data Exchange (SPDX) working group. With over 20 years’ software industry experience, Phil came to Black Duck from Empirix where he served as Vice President of Business Development and in other senior management positions, and was a pioneer in VoIP testing and monitoring. Prior to Empirix, Phil was a partner and ran consulting at High Performance Systems, a startup computer simulation modeling firm. He began his career with Teradyne's electronic design and test automation (EDA) software group in product, sales and marketing management roles. Phil has an AB in Engineering Science and an MS in System Simulation from the Thayer School of Engineering at Dartmouth College.


More from Managing security risks