March 20, 2026

Technical Due Diligence in M&A

When a Lawyer Starts Reviewing GitHub Repositories

Recently, I represented the buyer in an M&A deal targeting a SaaS startup. In traditional legal due diligence (DD), lawyers usually only focus on labor contracts, equity structures, financial statements, and a bunch of highly inflated "software copyright" certificates.

However, I requested the target company to grant access to their core GitHub repositories and pulled the complete architectural configuration files. As it turned out, this decision saved the client tens of millions in potential losses.

Hidden Landmine 1: The "Poison Pill" Contagion of Open-Source Licenses (IP Flaws) Traditional IP DD only checks for registered trademarks and software copyrights, completely ignoring the codebase's package.json or requirements.txt. While reviewing their core algorithm modules, I used an automated script to scan the code and found they directly invoked an open-source library under the AGPL-3.0 license. In the open-source community, AGPL is known as a "highly infectious" license. This means that once the M&A is completed and the module is integrated into the buyer's commercial closed-source product, the source code of the buyer's entire main product line will be forced to be open-sourced to the public. This is not only a compliance disaster but also directly leads to the valuation of this module dropping to zero instantly.

Hidden Landmine 2: Hardcoded "Digital Backdoors" (Cybersecurity Compliance Risks) While inspecting their backend code and CI/CD configuration files, we discovered that the former CTO, for the sake of convenience, had directly hardcoded the Root access keys (AK/SK) for multiple cloud servers in the code, without any environment variable isolation or the use of a Secrets Manager. What does this extremely amateurish security practice mean? It means the target company's core data assets are constantly running naked. Once the deal is closed, any data security incident caused by historical code leaks will result in massive fines and criminal liabilities under the Data Security Law, with the buyer taking the blame.

Hidden Landmine 3: Fake Privacy Protection (Violations in Cross-Border Data Transfer and PII Protection) The target company claimed in the DD questionnaire that they "fully comply with the Personal Information Protection Law (PIPL)" and provided a thick privacy policy document. But when I reviewed their database schema and underlying routing configurations, I found that users' sensitive Personally Identifiable Information (PII) was not only unencrypted at the storage layer (stored in plaintext), but the traffic of some of their API endpoints completely bypassed TLS encryption, exposing it to Man-in-the-Middle (MITM) hijacking risks. This phenomenon of "compliance on paper, violation at the bottom layer" can only be exposed by diving deep into the code level.

Conclusion In the digital economy era, an M&A lawyer who doesn't understand code is like an investor who doesn't understand finance. The true core trade secrets and fatal compliance landmines are rarely written in glossy due diligence reports; instead, they are hidden in those obscure commit logs, routing rules, and configuration files.