Solving the “Bottom Turtle” Problem in Supply Chain Security

Software supply chain security is like a stack of turtles—each layer depends on the integrity of the one below it. Continuous vigilance is key to maintaining security all the way down.

Michael Lieberman

December 18, 2024

Software supply chain security is like a stack of turtles—each layer depends on the integrity of the one below it. This "bottom turtle" problem highlights the cascading risks of compromised dependencies. To secure your supply chain, you need to establish trust at every layer, align with your risk appetite, and leverage tools for visibility and observability. Whether it’s securing foundational components or managing external libraries, continuous vigilance is key to maintaining security all the way down.

‍

Software supply chain security is a recursive problem. If a supply chain compromise came from an external dependency, then those dependencies themselves can just as easily be compromised by their external dependencies. And those dependencies can be compromised by their dependencies. And so on. Ensuring the security of all dependencies is crucial for mitigating risks in the software supply chain and maintaining the overall security of software products.

‍

What is the “bottom turtle” problem?

The recursive property of the supply chain means you need to apply supply chain security practices to your systems and verify that your dependencies do the same. Verifications can be done ad infinitum and leads to what is often referred to as “the bottom turtle problem.” This is a metaphor to represent the foundational components or dependencies upon which a software product relies. Just like the proverbial stack of turtles holding up the Earth in some myths, software often relies on layers of dependencies, with each layer built upon the ones below it.

‍

How dependencies affect security

In the context of supply chain security, securing the "bottom turtles" involves ensuring the integrity and security of the foundational components and dependencies upon which a software product relies. This can include libraries, frameworks, operating systems, and other fundamental software components. When foundational components are compromised or vulnerable, it can have cascading effects on the security of the entire software supply chain.

‍

For example, you might have security practices that thoroughly check your code for vulnerabilities. But if a library that you use becomes compromised, then your application can be vulnerable anyway. This nearly happened with the xz backdoor incident in early 2024. If you don’t manage your dependencies securely, the work you put into the top layer may be in vain.

‍

Securing the turtles

A fundamental principle of supply chain security is in establishing trust at levels and with parties that fit your risk appetite. There is no single right answer; the risk a mobile game startup is willing to take will be different from the risk a bank is willing to take. You have to understand the risks you’re willing to take and your threat model.

‍

Once you understand your risk appetite, you can take the appropriate actions. This could be establishing a root of trust — an inherently-trusted component that provides cryptographic functions for other components — with your processor manufacturer and enforcing that all software is signed with the trusted platform module (TPM). Or you might establish trust with software vendors that you know personally and trust their identities through signing secrets like keys and certificates. These vendors would do the same for the vendors that they depend on.

‍

Securing your software supply chain is not a one-time act; you have to continually be aware of what’s happening in the layers below your code. It’s difficult to keep up with all of this by hand. Supply chain observability tools that automatically aggregate data give you the visibility that you need to have security all the way down.

Like what you read? Share it with others.