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 to identify hidden problems that might devalue the property, impact negotiations or add to post-close plans. 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)
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. And, of course, AI comes up in every software conversation these days.
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 a walk-through of the target’s AppSec program at a high level. A disclosure request might include documented processes for using open source, handling vulnerabilities, building in security, AI usage 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. Audits delve deeply into all aspects of the code and focus on open source, application security, architecture, and quality. This kind of analysis is well-suited to a trusted third party because targets will not share their code with a potential acquirer. The exhaustive analysis Black Duck® 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 requires willingness to crawl into the farthest corners of the dusty attic). Bringing such expertise to bear is what distinguishes an audit from a mere automated scan.
Today, audits also scrutinize AI-generated code—an increasingly common component of target company codebases. AI coding tools can introduce open source snippet risks and novel security vulnerabilities that require the same rigorous inspection as human-written code. Additionally, many applications today incorporate AI model which also require special scrutiny.
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 can affect timing, terms or even deal valuation. Newly discovered vulnerabilities or open source license compliance issues may need to be remediated before close. Impressive AI claims may prove “not so much,” undercutting valuation. 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.
