Consider this: During your last audit, your regulator tells you to acquire an SBOM for your most critical software. The vendor complies and produces one. But now that you have the document, you're not too sure what it protects you against, or how it relates to the software escrow arrangement you already have in place. Are they covering the same risk? Do you now have unnecessary processes in place? Is one enough?
In the post below, I'll break down how they differ and why just one or the other isn't enough.
But your main takeaway should be this: SBOM and software escrow exist to solve different problems that you'll face in the midst of a software recovery. Understanding which problem each one solves is a good way to know whether you have any gaps.
In technical terms, an SBOM — Software Bill of Materials — is a machine-readable inventory of all the components a piece of software is built out of: every code snippet, library, dependency, version, and license.
In simpler terms, it's an ingredient list.
When you ask a vendor for their SBOM, you're asking them to show you exactly what they threw together to create their software. On its own, the SBOM offers a clean insight into what you'll need to get your hands on if you ever need to recover.
But you can also run it through a security scanning tool. Think of it like looking up the nutritional value of an ingredient. These tools will cross-reference every component against known vulnerability databases and flag any outdated libraries, unmaintained dependencies, and licenses that might conflict with your compliance requirements.
It's clear, then, why it's vital for risk management. But while the SBOM describes what the software is made of, it doesn't give you access to it. If the vendor folds, gets acquired, or discontinues the product, you'll be left with a shopping list to fix your software, but no way of accessing it — or, for that matter, knowing how to put it back together yourself.
Software escrow approaches the problem from the other side. It ensures you'll have access to the necessary ingredients (source code, documentation, and supporting materials) when you need to recover.
Under an escrow agreement, these components are held in an encrypted vault until certain conditions trigger a release: vendor insolvency, bankruptcy, discontinued support, or material breach.
In addition to all the components, it also usually captures build instructions and operational knowledge for how they're supposed to be put together to rebuild the software you need. Instead of just mitigating risk, it offers the business continuity you need to keep everything running.
But what escrow on its own doesn't give you is a separate inventory list. You'll be able to put everything together, but you might not know if you're missing anything. Your vendor could have forgotten to include several components, and without an SBOM, you wouldn't know what they left out or even what to look for.
Codekeeper software escrows include a full asset summary — a list of everything that's been deposited and when. If you're the beneficiary, you can request access to it directly from the depositor at any time.
While both are vital for vendor risk management, relying on just one can have some drawbacks.
SBOM with no escrow: You take on a new software system to solve a major bottleneck. Just to be safe, you request an SBOM and start running the listed materials through security tools. You identify a list of potential issues and set up failsafes, security protocols, and backup systems. When the vendor goes bankrupt, and your access disappears, you're not caught completely off guard — some damage control measures are already in place. But full recovery is still out of reach.
Escrow with no SBOM: A trigger condition is met. The deposit is released. Your team works through the build instructions, connects the external systems, and dials in the configurations. It's not working. You triple-check everything, but you definitely followed the instructions correctly. Something is missing. The vendor is gone, so you can't ask them what, and without an SBOM to consult, you have no way to identify which components aren't accounted for.
Neither of those gaps are due to flaws in either tool. It's just that they solve different but closely related problems.
SBOMs and software escrow work better together — well enough that regulators flag the combination during audits, and it's being written into compliance policies:
DORA requires documented ICT third-party risk management, including continuity plans for critical software dependencies. Escrow provides the continuity mechanism; an SBOM supports the dependency mapping those plans rely on.
CRA (EU Cyber Resilience Act) mandates that manufacturers of products with digital elements sold in the EU create and maintain a machine-readable SBOM covering all top-level dependencies. For any vendor selling into regulated European markets, this is now a standard procurement requirement.
NIS2 explicitly calls for supply chain security measures, including visibility into software dependencies — which is where SBOM comes in. Article 21(2)(c) requires business continuity planning for the systems your organization depends on — which is where escrow fits the bill.
These frameworks are all pushing in the same direction. Visibility and access continuity are both treated as requirements, not alternatives.
The SBOM maps out what the software depends on and acts as an early warning system for unstable components. The escrow agreement gives you legal and operational access to everything if the relationship ends. And the two together ensure you can rebuild a fully intact version of the software you depend on.
But until you need to suddenly recover, you won't know there's something missing. Verification closes the loop. Codekeeper's Certified verification runs build tests on deposited materials to make sure the full software will be rebuildable and deployable when the time comes. It also makes sure all components stay current with automatic syncing — there's no use recovering an out-of-date system.
With the verification in place, you also receive a Software Resilience Certificate that proves the deposits are complete and ready. So next time an auditor asks for proof of continuity, you can just hand over the certificate.
» Find out how you can improve your vendor risk management with software escrow
Managing third-party risk is complicated. With all the tools out there, it's tough to see when you're using redundant systems effectively covering the same risk. Few systems are truly as complementary as SBOM and software escrow. Together, they offer a path to independent recovery so effective that a vendor closure is more an inconvenience than an all-out disaster scenario.
» Wondering if your disaster recovery plan can rebuild the software you need? Take a look at how Codekeeper's Verification testing works with Software Escrow to ensure true continuity.