Open source dependency risk in B2B SaaS diligence.

We have written in the Cobalt Glacier B2B SaaS due diligence checklist about the six diligence workstreams every deal walks through, and in how we underwrite a software acquisition for a 25-year hold about the filters every deal has to clear. The dependency workstream sits inside the technical diligence stream and rarely changes the decision to do a deal — but it regularly changes the conditions of the deal and the work plan for the first year after close.

The license question, in its right size

License risk in B2B SaaS open source dependencies is real but bounded. Strong copyleft licenses (GPL, AGPL) inside a hosted SaaS product create distribution and source-disclosure obligations that most acquirers are unwilling to take on, and we walk from any target where a copyleft package sits in a code path that the SaaS offering reaches at runtime. Permissive licenses (MIT, Apache, BSD) carry roughly no commercial risk in the normal course. The standard diligence report does a fine job here. The risk is bounded because the license is usually static, and when it is not, the change is well-publicized.

The license tells you what you can do with the package today. It does not tell you what happens to your product if the package is abandoned tomorrow, relicensed next quarter, or compromised next week. Those three questions are the ones an underwriting memo has to answer.

Risk one: license drift

License drift is the increasingly common pattern of a permissive open source package being relicensed by its maintainers under a more restrictive variant, usually in response to commercial pressure from large cloud providers. The pattern is well-established in the database and observability categories and has spread to other infrastructure layers over the last several years. On a twenty-five-year hold, the probability that any widely-used infrastructure dependency a brand carries will relicense at least once is not low.

The remediation is to identify the three to five dependencies whose relicensing would create the most operational pain, and for each of them, pre-stage a replacement option. The pre-staging does not require replacing the dependency today. It requires knowing what the replacement would be, what the migration cost would be in engineering weeks, and which team would own the work. The brands that have this pre-staged absorb a relicensing event in a quarter. The brands that do not absorb it in a year, with all the disruption that implies.

Risk two: maintainer collapse

A surprisingly large share of the dependencies a typical B2B SaaS product carries are maintained by one or two people working in their personal time. When those maintainers move on, the package stops getting security updates. On a long hold, the maintainer-collapse risk compounds: every additional year the package goes un-maintained is a year of security debt the brand is carrying for the cost of zero dollars on its invoice and a real risk on its breach exposure.

We score each direct dependency on maintainer health during diligence using a small number of public signals — commit cadence, contributor count, time since last release, age of the open security issues. The output is a rank-ordered list of the dependencies most likely to require remediation in the first three years of the hold. The remediation options are usually one of three: fork the package and maintain internally, replace the package with a maintained alternative, or fund a maintainership stipend through one of the existing open source funding mechanisms. The right answer is package-specific and is part of the post-close work plan.

Risk three: supply-chain compromise

Supply-chain compromise is the risk that a dependency the brand consumes is altered, either by a malicious commit landing in the upstream project or by a registry account takeover that injects a compromised version of the package. The frequency of these events has grown meaningfully over the last several years, and the downstream cost to a SaaS brand that ships a compromised dependency can be operationally severe and reputationally severe in equal measure.

• Lockfile discipline. Every direct and transitive dependency is pinned by hash, not by version range. This is not exotic and is missing more often than it should be.
• Build provenance. The build pipeline produces a signed attestation of which dependencies went into which artifact. Available out of the box in most modern CI systems and rarely turned on in acquired brands.
• Update review. A weekly review of dependency updates, with at least one engineer accountable for approving any non-patch bump on critical-path packages. The cadence is the cheap part and the most often skipped.

The diligence workstream

We run the dependency workstream in parallel with the rest of technical diligence, usually over two to three weeks. The output is a single document scoring each direct dependency on the three risks above, a top-ten list of dependencies that drive most of the aggregate risk, and a remediation plan that becomes part of the first-year operating plan after close. The plan is almost never long. Most brands have between five and fifteen dependencies that account for nearly all of the risk, and addressing those is a tractable engineering project on a defined timeline.

What this does and does not change about a deal

In the vast majority of cases, the dependency workstream does not change the decision to do a deal. It changes the conditions: a representation or warranty around license posture, a defined remediation budget inside the first-year operating plan, and occasionally a small purchase-price adjustment when the remediation cost is large enough to be material. The reason to run the workstream is not to find reasons to walk. It is to underwrite the steady-state cost of operating the software for the next two decades and to make sure the team has a plan for the events that, on a long hold, are not low-probability.

How the workstream sits next to first-party engineering risk

The dependency workstream sits alongside, not inside, the first-party engineering diligence. The first-party diligence asks whether the code the target wrote is well-architected, well-tested, and operable by a small team for years. The dependency workstream asks whether the code the target depends on will continue to be available, maintained, and trustworthy for the same horizon. Both questions matter. The first is the more visible and the second is the more often under-scoped. We run the two workstreams with overlapping but distinct teams so that neither set of questions absorbs the other, and we produce two separate sections of the diligence memo so the conditions of close map cleanly to whichever set of issues needed remediation. The discipline of keeping the two questions separate is part of why our technical diligence catches a class of issues that combined workstreams routinely miss.

The bottom line

Open source dependency risk in B2B SaaS is a three-axis problem — license drift, maintainer collapse, and supply-chain compromise — and a one-axis diligence process catches only the smallest of the three. Cobalt Glacier runs a dependency workstream on every deal that scores each direct dependency on all three axes and produces a remediation plan as a condition of close. The cost of the workstream is two weeks of senior engineering time. The cost of not running it, compounded over a twenty-five-year hold, is several orders of magnitude higher.

If you are an investor evaluating Cobalt Glacier's underwriting discipline on the technical side, start a conversation with our investor team. The dependency workstream is one of several technical workstreams that distinguish how we underwrite for a twenty-five-year hold rather than a five-year flip.