In 2023, a mid-size fintech company discovered that one of its core payment processing vendors had quietly filed for bankruptcy. The vendor's SaaS product went offline. The fintech's engineering team had no access to source code, no documentation beyond API specs, and no way to migrate to an alternative without months of development work. They lost three weeks of revenue processing capability.
This scenario plays out more often than the industry acknowledges. Vendor failure, acquisition, or strategic pivots can cut off access to software your business depends on. Software escrow is the traditional mitigation, but most implementations are poorly structured and untested. They provide a false sense of security.
What Software Escrow Actually Is
Software escrow is a legal arrangement involving three parties: the software vendor (depositor), the customer (beneficiary), and a neutral third party (escrow agent). The vendor deposits source code, build scripts, documentation, and other materials with the escrow agent. If predefined release conditions are triggered -- typically vendor bankruptcy, failure to maintain the software, or material breach of the license agreement -- the escrow agent releases the deposited materials to the customer.
The theory is sound. The execution is where things fall apart.
Why Traditional Escrow Fails
Stale Deposits
Most escrow agreements require periodic updates, often quarterly or annually. In practice, vendors treat escrow deposits as an afterthought. The initial deposit might be complete, but subsequent updates are often late, incomplete, or entirely missing. By the time a release condition is triggered, the escrowed code might be 18 months behind production.
For SaaS products, this gap is catastrophic. The escrowed code might reference infrastructure that no longer exists, depend on services that have been deprecated, or lack the database migrations needed to run against the current data schema.
Incomplete Deposits
Source code alone is not enough to rebuild a software product. A complete escrow deposit should include:
- Source code for all components (frontend, backend, APIs, background jobs)
- Build scripts and CI/CD configuration
- Infrastructure as Code templates (Terraform, CloudFormation, etc.)
- Database schemas and migration scripts
- Third-party dependency manifests and lock files
- API keys and service configurations (or documentation of required integrations)
- Build and deployment documentation
- Test suites
- SBOMs for all components
Most escrow deposits include source code and maybe a README. That is not enough to actually run the software.
No Verification Testing
The most critical flaw in traditional escrow is that nobody verifies the deposit actually works. The escrow agent stores whatever the vendor sends, but nobody tries to build, deploy, and run the software from the escrowed materials. When the release condition triggers and the customer finally tries to use the deposit, they discover missing dependencies, broken build scripts, and undocumented configuration requirements.
Verification testing -- actually building and deploying the software from the escrowed materials -- should be performed at every deposit update. Some escrow agents offer this as a service, but it is expensive and rarely included in standard agreements.
Modern Alternatives to Traditional Escrow
SaaS Escrow and Data Export
For SaaS products, source code escrow is often insufficient. You cannot run a SaaS product locally without its infrastructure, third-party integrations, and operational knowledge. Modern SaaS escrow focuses on:
Data export: Ensuring you can extract your data in a usable format. This is more immediately valuable than source code. If the vendor fails, you can migrate your data to an alternative product rather than trying to run the vendor's code yourself.
API documentation escrow: Full API documentation allows you to build integrations with alternative providers or develop an in-house replacement that is data-compatible.
Infrastructure replication: Some escrow agents maintain a standby deployment of the vendor's software in a separate cloud account, ready to activate if the vendor fails. This is expensive but provides genuine continuity.
Open Source Dependencies as Escrow Risk
There is an overlooked escrow dimension in open source software. When your vendor's product depends on 500 open source packages, those packages are not part of the escrow deposit. If the vendor goes bankrupt and you try to build from the escrowed source code, you need those packages to be available on their public registries.
This is usually fine -- npm, PyPI, and Maven Central are not going anywhere. But specific packages can be unpublished, removed, or compromised. The left-pad incident proved that a single removed package can break thousands of builds.
Mitigation: include a vendored copy of all dependencies (or at minimum, the lock file and a copy of all dependency tarballs) in the escrow deposit. Better yet, include a container image of the fully built application.
SBOM-Based Continuity Planning
An SBOM provides a complete inventory of every component in a software product. In a continuity scenario, the SBOM tells you exactly what you need to rebuild:
- Which open source libraries are required, at which versions
- Which proprietary components exist and need replacement
- Which build tools and runtimes are needed
- What the license obligations are for each component
This information is valuable even without source code. It tells you the scope of a replacement effort, helps you evaluate alternative products, and identifies which components you might be able to source independently.
Structuring Effective Escrow Agreements
If you are going to invest in software escrow, structure the agreement to actually protect your interests:
Release conditions should be specific. "Material breach" is too vague. Define specific triggers: failure to provide security patches within a specified SLA, failure to maintain uptime above a threshold, change of control to a specified competitor, insolvency filing.
Deposit requirements should be detailed. Enumerate exactly what must be deposited: source code, build scripts, infrastructure templates, dependency manifests, lock files, SBOMs, deployment documentation, test suites, and container images.
Verification testing should be mandatory. Require annual verification testing where the escrow agent (or a third party) builds and deploys the software from the escrowed materials. The cost is significant but the alternative is a deposit that does not work when you need it.
Update frequency should match release cadence. If the vendor releases monthly, quarterly escrow updates mean the deposit is always outdated. Require deposits within 30 days of each production release.
Escrow should include build environment. Container images of the build environment, or at minimum detailed build environment specifications, prevent the "works on their machine" problem when you try to use the deposit.
Vendor Risk Assessment for Supply Chain Continuity
Escrow is one control in a broader vendor risk management program. Other continuity measures include:
Multi-vendor strategy. Do not depend on a single vendor for critical capabilities. Maintain the ability to switch, even if you do not exercise it. This is easier when you use abstraction layers and standard APIs rather than deep proprietary integrations.
Financial health monitoring. Track your vendors' financial health through credit monitoring services, SEC filings (for public companies), and industry intelligence. Early warning of financial distress gives you time to prepare.
Contractual protections. Beyond escrow, ensure your contracts include data portability rights, reasonable termination provisions, and transition assistance obligations.
Relationship diversification. For open source dependencies, prefer projects with multiple corporate sponsors, active contributor communities, and foundation governance. A project maintained by a single developer at a single company is a concentration risk.
How Safeguard.sh Helps
Safeguard.sh strengthens your supply chain continuity posture by maintaining comprehensive, always-current SBOMs for every software product in your portfolio. When a vendor fails or a critical dependency becomes unavailable, Safeguard.sh gives you an immediate inventory of affected components and their alternatives. The platform tracks vendor concentration risk -- showing you which vendors and open source projects represent single points of failure -- and provides the dependency intelligence needed to evaluate replacement options quickly. For escrow deposits, Safeguard.sh-generated SBOMs serve as a verified manifest of what the deposit should contain.