Identifying Code Risks in Software M&A
Most CEOs and founders in the software space when thinking about or preparing for a potential exit focus on table stakes metrics (ARR run rate, churn, growth rate, etc…) And yes, these metrics are of the highest importance to would-be acquirers. And of course meeting or exceeding, industry benchmarks here will make your organization a very attractive acquisition target. But there are often overlooked components that are almost always thoroughly examined during the due diligence process. One of these components is the actual software code and architecture.
Source Code Issues
I’ve almost never met a founder, and especially one with an engineering background who isn’t confident in the strength and viability of their software code. But there can be a significant risk that lies beneath the surface from years and years’ worth of development efforts and fast-tracked version releases.
Risks around poorly written components of source code and technical debt can create significant issues. During the due diligence process, the lion’s share of would-be acquirers will do a thorough technical audit of the source code to identify potential red flags. No software is perfectly written, and educated buyers will understand that. But major issues with how the software has been written or the amount of technical debt that has mounted can pose a real threat in the M&A process.
Typically conducted by a third-party provider a technical audit is a 2–4 week process that will analyze components of the selling organization’s code. This audit will typically focus on items that include:
· Analysis of the software architecture
· Third-party service integration analysis
· Database design
· Code release and testing practices
· Software code and system maintainability
A third-party code audit can reveal technical debt or in rare cases major issues and flaws with how the software was built, all red flags that can negatively impact an acquisition process.
Open Source Code
Leveraging open-source software within a commercial software solution of course offers many benefits. But conversely, it can come back to haunt software companies during an M&A transaction.
The very nature of open-source software presents complex licensing conditions, security risks, and intellectual property risks that a buyer could potentially inherit. Today more and more companies are using open source as a significant component of their codebase. Some estimates have the average amount of open-source software in a company’s codebase at around 60% — 70%.
So for acquirers, they must make a thorough assessment of how real those previously mentioned risks are. And if that open source code is fraught with licensing issues, and potential security risks it can be enough to cause them to walk away.
Security & Vulnerability
The potential security risks posed by open-source code dovetail into the broader issue of security and vulnerability. Software code with significant vulnerabilities can end up creating a significant liability for a buyer post-acquisition.
Seasoned software acquirers will likely want to run a third-party penetration test (pentest) as part of their cybersecurity due diligence on a software company. A pentest will typically look for vulnerabilities and examine areas that include:
领英推荐
? Encryption and authentication
? Code and command injection
? Configuration of networks and devices
? Likelihood of attacks and the possible impact of those attacks
As is the case with a technical audit, the third party who executes the penetration test will deliver the report to both the buyer and the seller for review.
Effectively Interpreting Audit & Testing Outcomes
Ninety-nine percent of the time a senior technical resource at both the buyer and seller will be involved in the technical due diligence process. However, it’s incredibly important that non-technical resources especially those who reside with the buyer understand the true implications of the findings of a technical audit and pentest. Often times the findings of a technical audit or pentest can flag items that show an issue. And while at first blush these may seem like major issues they are often fixable and not as damning as they initially appear to be.
Be Prepared
For the vast majority of software companies eventually being acquired is the end game. So knowing a rigorous due diligence process that will include deep technical due diligence is next to inevitable it’s important to be prepared.
1. Quality In > Qualify Out: This goes without saying but hiring top-tier engineering talent (albeit challenging) and following best practices for engineering a well-built product is a sure-fire way to avoid issues down the road. This means avoiding or limiting the amount of development work that is outsourced, and if you choose to outsource do so with a great degree of caution and scrutiny.
2. Understand the potential long-term implications of open source code: It’s unrealistic to assume that a sizeable portion of a commercial software solution won’t be open source. But taking into account potential long-term risks when selecting those open source components should be a high priority. The risk factors that must be taken into consideration include; security vulnerabilities, licensing compliance risks, and overall code quality.
3. Conduct periodic code audits and pentests: The nice thing about conducting periodic software code audits and penetration testing is it ensures you’re developing a sound software solution that is secure and will perform at a high level. All of which carry value when it comes to keeping customers happy. And making this a regular practice will naturally avoid any major issues when you get to a place where you’re deep in due diligence with a potential acquirer
The process of engaging with potential acquirers and navigating all of the twists and turns of the due diligence process is time-intensive, expensive, and emotionally exhausting. The last thing a CEO or founder wants is a scenario where issues lying beneath the surface derail an acquisition and lots of hard work.
Understanding what lies ahead in the due diligence process and being more than adequately prepared will help avoid an unfortunate outcome.
A PowerPoint version can be viewed at: https://tinyurl.com/mw7wneua