Software escrow is a risk management mechanism where a vendor deposits source code, build instructions, and other materials with a neutral third party. If the vendor goes out of business, breaches the contract, or otherwise fails to maintain the software, the customer can access the escrowed materials.
The concept is straightforward. The execution is where things get complicated, especially from a security perspective.
Why Escrow Matters for Security
Your security tooling, vulnerability scanning, and patch management depend on the vendor continuing to operate. If your SCA vendor disappears, you lose vulnerability monitoring for your entire dependency tree. If your SBOM platform vendor shuts down, you lose the SBOM history that regulators or customers may require.
Escrow ensures continuity, but only if the escrowed materials are complete, current, and usable. Most standard escrow agreements fall short on all three.
What to Include in the Escrow Deposit
Source Code Is Not Enough
A tarball of source code is useless without the ability to build, deploy, and operate the software. Your escrow agreement should require:
Complete build instructions. Documented, tested instructions for building the software from source. Include specific compiler versions, build tool versions, and operating system requirements.
Dependencies and dependency manifests. All third-party dependencies, with exact versions, must be either included in the deposit or obtainable from documented sources. If the vendor uses private packages, those must be included.
Infrastructure-as-code. If the software runs on cloud infrastructure, the deployment configuration (Terraform, CloudFormation, Kubernetes manifests) should be included.
Database schemas and migration scripts. The escrow deposit should include everything needed to set up and migrate the database to the current version.
Cryptographic keys and certificates. If the software uses encryption, signing, or TLS, the necessary keys and certificates (or instructions for generating them) must be included.
Security-Specific Materials
Vulnerability database access. If the vendor maintains a proprietary vulnerability database, the escrow should include the database or a license to access it.
API keys and service credentials. If the software integrates with third-party services, the escrow should include the credentials needed to maintain those integrations (or documented procedures for obtaining new credentials).
Security documentation. Architecture diagrams, threat models, and known vulnerability lists help the team that takes over the software understand its security posture.
Verification Is Non-Negotiable
An escrow deposit that has not been verified is an escrow deposit that might not work. Require periodic verification testing where the escrow agent (or an independent technical party) builds the software from the deposited materials and confirms it functions correctly.
Verification frequency. At minimum, verify annually. For critical software, verify after every major release. The deposit should be updated with every significant version change.
Verification scope. Building the software from source is the minimum. Ideally, verification should include deploying to a test environment, running the test suite, and confirming basic functionality.
Security Risks of Escrow
Escrow deposit as attack surface. The escrow deposit contains your vendor source code, credentials, and infrastructure configuration. If the escrow agent is compromised, this information is exposed. Evaluate the escrow agent security practices as seriously as you would evaluate the vendor.
Stale deposits. If the escrow deposit is not updated regularly, you may end up with source code that is years behind the version you are running. Building and deploying an old version introduces known vulnerabilities that have been fixed in newer releases.
Dependency rot. Even if the source code is current, the dependencies it requires may no longer be available. npm packages get unpublished, Docker base images get removed, and API services shut down. The escrow deposit should include cached copies of critical dependencies.
Negotiation Checklist
- Deposit includes source code, build instructions, dependencies, and IaC
- Deposit is updated with every major release
- Independent verification testing occurs at least annually
- Escrow agent has adequate security certifications
- Release conditions are clearly defined
- Deposit includes security-relevant documentation
- Your team has right to verify the deposit independently
How Safeguard.sh Helps
Safeguard.sh helps you maintain continuity in your supply chain security program regardless of vendor status. Our SBOM generation, vulnerability tracking, and dependency monitoring create data artifacts that you own and control. If you need to transition between security tools, your Safeguard.sh data -- SBOMs, vulnerability history, dependency inventories -- transfers with you in standard, open formats.