The package.json lies by omission
Picture a founder walking you through his platform's dependency list during diligence — 47 direct packages, all reputable, all reasonably current. Clean, he says. He's telling the truth about the part he can see. Run the full graph and those 47 packages pull in north of 2,000 transitive dependencies — the libraries his libraries depend on, and the libraries those depend on, several layers down. He has never seen that number. Neither has his CTO. That gap between the 47 they manage and the 2,000-plus they actually ship is the thing you are buying, and the seller has no idea what's inside it.
This is the structural reality of modern software acquisition. Per the 2024 Synopsys Open Source Security and Risk Analysis report, open source makes up roughly 77% of the average application's code, and 96% of commercial codebases contain it. So when you price a software target as a proprietary IP asset, you are mispricing it. The proprietary part — the founder's actual differentiation — is the thin top layer. Most of what you're acquiring is inherited code that nobody on the team wrote, reviewed, or has thought about since the day npm install ran.
The danger isn't that open source is bad. It's that a working demo tells you nothing about the maintenance posture underneath it. An application can pass every functional test, sail through the product walkthrough, and still be sitting on a version of a core library that was flagged years ago. "It works" and "it's safe to own" are different questions, and functional diligence only answers the first one.
Where the money actually leaks: the layers nobody scans
The expensive risk is almost never in the direct dependencies. It's in the transitive ones — and a scan that only reads the top-level manifest can miss the large majority of the dependency graph entirely. That's not a rounding error. If a target carries 50 direct packages and 2,000 transitive ones, and your scan stops at the manifest, you've audited about 2.5% of what you're acquiring and declared the rest fine.
This is also where the supply chain has gotten genuinely adversarial. Sonatype's 2024 State of the Software Supply Chain report documents a 156% year-over-year jump in malicious packages — and these don't announce themselves as direct dependencies. They slip in deep, several hops down, riding inside a package that a package that a package needs. A team can have spotless top-level hygiene and still be running an abandoned or poisoned library four levels beneath anything they've ever looked at.
The reason this matters for deal math: remediation cost is not linear with depth. Swapping a stale direct dependency is a controlled change. Replacing an abandoned transitive one — buried under a chain of packages that were each pinned to specific versions for reasons no current engineer remembers — is a structural refactor that ripples upward through the whole tree. And the further you push a fix toward a live, customer-facing system, the more it costs: addressing a vulnerability in production runs roughly 30x what it costs to handle the same issue earlier in development. When you inherit deep transitive rot, you're not buying engineering hours to swap a library. You're buying regression testing, change windows, customer notifications, and the very real chance that one upgrade cascades into ten. In technical diligence, this belongs in the post-close budget as a hard CapEx line, not a footnote.
Three numbers to demand during exclusivity
Stop accepting a green "no critical CVEs" screenshot from the seller's tooling. A clean scan tells you what's on fire today; it tells you nothing about what it costs to make this codebase safe to own. Reframe the entire exercise around one question your investment committee actually cares about: what is the dollar cost to bring this dependency tree to an acceptable baseline? Three measurements get you there.
- LibYear drift, not just CVE count. LibYear sums how many years behind current-stable every dependency is. A codebase with low CVEs but high LibYear is more dangerous than it looks — it means a team that stopped maintaining, which means the eventual catch-up upgrade will break things in ways no one can scope until they try. Synopsys found stale components 10+ major versions out of date in a large share of audited codebases. High drift is a forward-looking signal that your first two quarters of roadmap get eaten by upgrade work.
- License contagion in the transitive layers. This is the one that masquerades as a technical problem and detonates as a legal one. Synopsys found license conflicts in 53% of codebases, and copyleft licenses like GPL love to hide in transitive dependencies — a package the founder never chose, pulled in three levels down. Discovering GPL load-bearing inside a product you're about to sell as proprietary IP isn't a patch; it can force an open-sourcing decision or a clean-room rewrite. Scope it before close, never after.
- Remediation translated into a CapEx figure. Convert findings to dollars in front of the seller. Say a scan surfaces 400 high-risk items and your engineering benchmark is four hours to remediate, regression-test, and validate each at a loaded $150/hour — that's a $240,000 line item before you count the roadmap quarters you're not shipping. Anchor it further with downstream exposure: IBM's 2024 Cost of a Data Breach report puts the average breach in the millions, which is what the unpatched version of this conversation costs.
Once dependency risk is a number instead of an adjective, you have leverage. You either negotiate it straight into the purchase price as the discount it is, or you carve out a dedicated technical-debt escrow sized to the cleanup — so the seller funds the maintenance they deferred, instead of you discovering it the hard way while your roadmap stalls the quarter after close.
