M&A code due diligence: what acquirers find in the first 48 hours

In a software acquisition, the diligence team will spend weeks on financials, customers, and contracts, and then value the actual asset, the codebase, on the strength of a management presentation. The buyers who do it differently have learned the same lesson, usually expensively: the first technical scans reprice deals, and they do it fast.

Here is what systematic code diligence finds in the first 48 hours, and why it changes negotiations.

Finding one: the license that constrains the asset

The highest-stakes discovery in software diligence is open-source license exposure: copyleft-licensed code combined into the product in ways that create obligations the seller never surfaced, sometimes obligations incompatible with how the buyer intends to commercialize the asset. Transitive dependencies and vendored copies are where it hides; a top-level license review misses both, which is why full-graph, SPDX-aware classification with per-component evidence is the diligence standard. The result is not always deal-breaking, but it is always price-relevant, and it is the finding legal teams most hate learning about post-close.

Finding two: the credentials still live in history

A full git-history secrets scan on a mature target repository essentially always returns findings: cloud keys, database credentials, signing material, committed across years and “deleted” into permanence. For diligence this reads two ways. Directly: post-close, the buyer inherits credentials of unknown exposure, and rotation becomes a day-one integration task with a checklist. Indirectly: the volume and age of leaked secrets is the single most honest proxy for the target’s real security culture, more honest than anything in the data room.

Finding three: known-exploited vulnerabilities in the shipping product

Not the raw vulnerability count, which is noise, but the specific intersection that matters: known-exploited and high-likelihood vulnerabilities in the product as currently shipped to customers. These are incidents-in-waiting that the buyer is agreeing to own, and their remediation cost belongs in the model. The same scan produces the SBOM the buyer will need anyway, because post-close, every new disclosure against the acquired product becomes the buyer’s question to answer.

Finding four: what the product actually contains

Generated component inventories routinely contradict the target’s own architecture narrative: end-of-life runtimes, abandoned dependencies with no upstream, components the engineering team did not know were bundled. Individually small, collectively these are the integration-cost line item, and the gap between the story and the artifact is, again, diagnostic of engineering discipline.

The deal-room constraint that shapes everything

All of this must happen under conditions normal tooling fails: the target will not, and should not, upload its source to a cloud scanner mid-negotiation, and leak risk paranoia runs appropriately high on both sides. The workable pattern is analysis that deploys entirely inside controlled infrastructure, a clean room either side can host, with nothing transmitted out. Determinism earns its keep here too: when a finding is disputed, and findings in diligence are always disputed, the target can reproduce the exact result themselves, which converts arguments into verifications.

For sellers reading this

The same four scans, run on yourself a quarter before going to market, cost little and change the negotiation: findings you disclose with remediation plans are process; findings the buyer discovers are leverage. Either way, the era of codebases being valued unexamined is ending, one repriced deal at a time. The clean-room setup takes a day; the surprises are cheaper to meet early.