Escrow of the source code is one of the necessary stages to ensure the protection of important software. But even in the case of having the source code, it doesn’t guarantee that the business will be able to reproduce the application in case the software provider disappears. In some cases, building the application can require certain tools, dependencies and configurations.
That is why it is necessary to have clear build instructions described in a source code escrow agreement. They indicate what the vendor should do to make it possible to rebuild the application.
What Are Software Build Instructions?
Software build instructions are the procedures that describe the way to convert source code into an executable software. They include the list of tools, configurations and other aspects necessary for reproducing the build process of the software.
Depending on the application, they can include:
- Source code and structure of the repository: Necessary files and directories, as well as their versions, to recognize the release of the software.
- Build tools and environment: Versions of operating system, programming language, compilers and frameworks.
- Dependencies: Necessary third party libraries, packages and credentials for accessing private repositories.
- Configuration files: Environment variables and settings required to prepare the build environment.
- Build scripts: Commands and automation files used to compile and package the application.
Why Is It Important to Include Build Instructions in a Source Code Escrow Agreement?
The presence of the source code does not necessarily mean that the application will be easy to rebuild. Although the company will get the code after the vendor fails, it might not have the necessary dependencies, build scripts or development environment for rebuilding the software.
For instance, the application might depend on the certain version of a compiler or the specific libraries stored in the vendor's private repository. In this case, it will be impossible to rebuild the software even with access to its source code.
Build instructions will make sure that this problem does not occur, as the technical prerequisites of rebuilding the application will be defined as a condition of the escrow deposit.
What Should Be Included in a Software Escrow Agreement?
The agreement must include the following requirements:
1. Build Environment and Tools
It is necessary to list the operating system, programming languages, frameworks, compilers and other development tools necessary for building the application. The version of these tools must be specified too, as they might cause problems otherwise.
2. Dependencies and Third Party Components
Make sure that the vendor provides an overview of all external libraries, packages, and proprietary components, as well as their corresponding version and licensing requirements. Make sure that the agreement outlines how the beneficiary will gain access to those components which are hosted by the vendor within its own repository post release.
3. Build Instructions
Make sure that the vendor provides step-by-step build instructions which a competent developer can understand without depending on any undocumented expertise from the initial development team. These must include the process for preparing the source code, setting up the environment, installing dependencies, executing build scripts and testing the application.
4. Configuration and Associated Documentation
Configuration files, database schemas, migration scripts, architectural diagrams and test cases should be part of the deposit. Credentials should not be stored in plain text.
5. Build Verification and Acceptance Criteria
The agreement should define how deposited materials will be checked and what constitutes a successful build.
| Verification step | What it checks |
|---|---|
| Deposit inventory | Whether required files and documents are present |
| Environment recreation | Whether the build environment can be recreated |
| Dependency check | Whether required components are accessible |
| Compile test | Whether source code can produce a build |
| Functional test | Whether the application performs specified functions |
A successful compile does not necessarily prove that the application can be deployed or operated. These requirements should be verified separately if independent recovery is the objective.
Why Escrow Build Instructions Need Updating
The vendor's software gets updated. It could introduce dependencies, framework updates and change the way of building the application. As a result, the escrow materials will become irrelevant.
Therefore, the agreement should state when and how often the build instructions are to be updated, identify versions, and stipulate whether the deposited instructions have to go through verification procedure.
How Castler Goes Beyond Build Instructions Verification
Setting up build instructions specifies what the vendor needs to deposit. However, a business needs proof that deposited materials can be used.
Castler is a Software Recoverability Platform (SRP) which independently verifies the ability to rebuild and deploy critical vendor software. The process involves dependency mapping, rebuilding the software in a clean environment, verification of its deployment against the declared architecture, and getting engineer's sign off.
As a result, a Proof of Recovery (signed, numbered) for the particular software release tested is provided. Depending on the scope and product tier, the proof may include Build Report, Deployment Runbook, Replication Report, SBOM, Confidence Score and Engineer's Seal.
It enables businesses to go from setting up the rebuild instructions to verifying their feasibility under tested conditions.
Conclusion
The source code escrow agreement needs to define more than just materials needed from the vendor to be deposited. Requirements for tools, dependencies, and processes needed to rebuild an application also need to be defined.
Castler assists businesses in going beyond the source code custody by independently verifying the software rebuild and deployment.
Frequently asked questions
1. Is there a guarantee that if a source code is deposited, software will be able to be rebuilt?
No, it is not guaranteed since the software may have requirements such as dependent libraries, proprietary tools, certain configurations, and repositories that are inaccessible. All those requirements also need to be deposited.
2. How often do we need to update our build instructions?
This needs to be done every time there is a change in a software release in terms of build process, dependencies, and the required environment. This should be established in an agreement.
3. What is the difference between build verification and software recoverability?
Build verification consists of checking the ability to compile a source code. Software recoverability is something more as it includes independent rebuilding and deployment of an application.