The 80% Liability You Didn't Know You Were Buying
In modern software M&A, you are rarely buying 100% proprietary code. You are buying a thin veneer of intellectual property sitting on top of a massive, unmanaged iceberg of open source software (OSS). According to the 2024 Synopsys Open Source Security and Risk Analysis (OSSRA) report, 96% of commercial codebases contain open source components, and these components make up approximately 77% of the average application's code. For Private Equity operating partners, this flips the traditional asset narrative: you aren't acquiring a software asset; you are acquiring a supply chain management problem.
The risk is not theoretical. The same report found that 74% of codebases contained high-risk vulnerabilities—a sharp increase from 48% in 2022. This is what we call the "Supply Chain Discount." When you acquire a target with unpatched third-party dependencies, you are inheriting "Zombie Code"—components that are 10 or more versions out of date, which were found in 91% of audited codebases. This isn't just technical debt; it is a latent security breach that will require immediate, expensive remediation post-close, often paralyzing the roadmap you built your investment thesis around.
For Portfolio Paul, the danger lies in the "it works" fallacy. A target's application may function perfectly during the demo, passing functional due diligence with flying colors. However, beneath the surface, it may be relying on a version of a library like Log4j that has been known to be vulnerable for years. If you fail to quantify the cost of remediating these dependencies before signing the deal, you are effectively agreeing to pay for the seller's years of deferred maintenance.
The Transitive Trap: Where the Real Risk Hides
The most dangerous risks in software due diligence are rarely the direct dependencies listed in a package.json file. They are the transitive dependencies—the libraries that your target's libraries rely on. Sonatype's 2024 State of the Software Supply Chain report highlights a 156% year-over-year increase in malicious packages, many of which infiltrate systems through these deep, unmonitored layers of the dependency tree. In fact, standard scans often miss up to 80% of transitive vulnerabilities if they only look at top-level manifests.
This creates a "Russian Doll" scenario for acquirers. You might audit a target and find their direct dependencies are relatively clean. But if you aren't running deep Software Composition Analysis (SCA) that traverses the entire dependency graph, you are missing the vast majority of the attack surface. We often see targets with only 50 direct dependencies but over 2,000 transitive ones. If even 5% of those deep dependencies are abandoned or malicious, the remediation effort is not a linear patch; it is a structural refactor.
This "Dependency Hell" has direct financial consequences. Fixing a vulnerability in production is approximately 30 times more expensive than fixing it during development. When you buy a company with deep transitive rot, you aren't just paying for the engineering hours to swap out a library; you are paying for the extensive regression testing, potential downtime, and customer communication required to patch a live system. In technical due diligence, this must be calculated as a distinct line item in your post-close budget (CapEx).
The Due Diligence Diagnostic: Quantifying the Remediation CapEx
Stop accepting a simple "clean" scan from the seller. To protect deal value, your technical diligence must move from "presence" to "remediation cost." You need to answer a specific financial question: What is the dollar cost to bring this codebase to an acceptable risk baseline?
We recommend a three-step analysis during the exclusivity period:
- The "Freshness" Audit: Don't just look for CVEs (Common Vulnerabilities and Exposures). Measure the "LibYear" drift—the total number of years your dependencies are behind the current stable versions. A high LibYear score indicates a team that has ignored maintenance for years, signaling that any upgrade will likely break the build.
- The License Liability Check: Synopsys found that 53% of codebases contained license conflicts. Discovering a copyleft license (like GPL) in a proprietary product post-close can be a catastrophic valuation event, potentially forcing you to open-source your IP. This is a legal risk that masquerades as a technical one.
- The Remediation Estimate: Calculate the "Security Debt" in dollars. If a scan reveals 400 high-risk vulnerabilities, and your benchmark is 4 hours to remediate and validate each at an engineer rate of $150/hr, you are looking at a $240,000 immediate expense—not including the opportunity cost of the product roadmap delays.
By treating third-party risk as a financial liability rather than a code quality metric, you can negotiate the "Supply Chain Discount" into the closing terms or require a specific technical debt escrow to cover the cleanup costs.
