企业并购中的技术尽调

最近，我代表买方参与了一起针对某 SaaS 初创企业的并购案。在传统的法务尽职调查（DD）中，律师通常只关注劳动合同、股权结构、财务报表以及一堆水分极大的“软件著作权”证书。

但我要求目标公司开放了他们核心代码的 GitHub 仓库权限，并拉取了完整的架构配置文件。事实证明，这个决定为客户挽回了数千万的潜在损失。

隐雷一：开源协议的“毒丸”传染（知识产权瑕疵） 传统的知识产权尽调只看有没有注册商标和软著，却根本不看代码库的 package.json 或 requirements.txt。在审查其核心算法模块时，我通过自动化脚本扫描，发现他们直接调用了一个采用 AGPL-3.0 协议的开源库。 在开源界，AGPL 被称为“极强传染性”协议。这意味着，一旦完成并购并将其整合进买方的商业闭源产品中，买方整个主产品线的源代码都将被迫向公众开源。这不仅是合规灾难，更直接导致了该模块在并购估值中的瞬间归零。

隐雷二：硬编码的“数字后门”（网络安全合规风险） 在排查其后端代码和 CI/CD 配置文件时，我们发现前任 CTO 为了图省事，直接在代码中硬编码（Hardcode）了多个云服务器的 Root 权限密钥（AK/SK），且未做任何环境变量隔离或使用 Secrets Manager。 这种极其业余的安全实践意味着什么？意味着目标公司的核心数据资产随时处于“裸奔”状态。一旦完成交割，任何因历史代码泄露导致的数据安全事故，其《数据安全法》下的巨额罚款和刑事责任，都将由买方来背锅。

隐雷三：虚假的隐私保护（数据出境与个人信息保护违规） 目标公司在尽调问卷中声称“完全遵守《个人信息保护法》”，并提供了厚厚的隐私政策文本。但当我审查其数据库 Schema 和底层路由配置时，发现用户的敏感个人信息（PII）不仅没有在存储层进行加密（明文存储），甚至其部分 API 接口的流量直接绕过了 TLS 加密，存在被中间人（MITM）劫持的风险。这种“纸面合规，底层违规”的现象，只有深入代码层才能被戳穿。

结语 在数字经济时代，不懂代码的并购律师，就像是不懂财务的投资人。真正的核心商业机密和致命的合规地雷，往往不写在光鲜亮丽的尽调报告里，而是藏在那些晦涩的 Commit 记录、路由规则和配置文件中。