Building a Foundation of Trust for a Stronger Software Supply Chain

Creating a secure foundation of trust enables organizations to safely delegate specific actions in the software development life cycle.

Michael Lieberman

February 20, 2025

Establishing a solid foundation for the trust in your IT environment is crucial to ensure the security and integrity of your software supply chain. When you have a chain of trust, you can safely delegate authority for various actions, such as attesting to the output of builds and signing software bills of materials (SBOMs). This ultimately promotes a secure and well-managed IT environment more protected from a supply chain compromise.

‍

Imagine you are working at a hypothetical bank called Secure Bank that had a software supply chain compromise. Instead of rebranding, Secure Bank decided to take steps to live up to the name. It begins to model threats to the various phases of our software development life cycle (SDLC) from planning through to maintenance and to design systems and processes that follow standards and best practices for securing the supply chain. Now where do you get started with implementing a more secure SDLC?

‍

Get started by establishing a root of trust! A root of trust is the starting point for the security processes and mechanisms within the IT environment. It serves as a basis for verifying the authenticity and integrity of various components in the system, such as software, hardware, and data. It is the foundation that all other trust within a system sprouts from.

‍

In a historical context, this would be something like the seal of a monarch. People could look at that seal and feel confident that a document with that seal was valid. In the contemporary IT security context this is often a cryptographic certificate. As you’ll learn, this root certificate can be based in hardware or software. This root certificate is then used to derive other certificates, keys, and cryptographic material that can be used for actions like authentication, encryption, and signing.

‍

By establishing a new root of trust in the right way, Secure Bank can better protect its environments — and ultimately its customers — from attack by ensuring the security processes and systems derive their authority from the root of trust. This means there must be a chain of trust or a set of relationships between the root of trust and all the other processes, systems, and data. If something appears within the network without a chain of trust that leads back to the root of trust, then something has gone very wrong.

Designing a trust chain

Throughout this post, you’ll see how the bank can look at establishing new roots of trust and determining the roles and permissions for the SDLC that become the foundation for a new, more secure SDLC. The bank might perform this in relation to an audit that determines their existing roots of trust are inadequate and prone to being compromised. This is can be due to:

Improperly secured root certificate authority (CA) private key.
Poor SDLC access controls potentially allowing attackers access to publish malicious packages to internal artifact repositories.

In the figure above, you can see what the bank wants to achieve. They want to establish trust in a root CA backed by a hardware root of trust that they can then use to create other certificates. These certificates are then used by other systems to delegate authority through various trust paths. The bank can set permissions so that the team responsible for the CI and build systems can only perform the actions they’re supposed to. The build systems can also connect identity through signing to the artifacts it produces through these same mechanisms. This allows the bank to establish identities in the teams and systems utilized within the SDLC that can be utilized within the identity and access management (IAM) systems within the bank. This lowers the blast radius of any compromise into a piece of our SDLC while also making it easier to audit where a software artifact came from, also known as its provenance.

Establishing roots of trust

Now that you know how an organization like Secure Bank should structure its trust paths, let’s explore how you can perform these operations. Start by establishing roots of trust securely within the bank. These are the cryptographic materials that would always be trusted within the environment. Choosing and securing roots of trust are critical, because if you utilize a weak or improperly secured key or set of keys that are your roots of trust it leads to all the trust paths that come out of that root of trust to be potentially compromised. This is an extraordinarily expensive operation that would require starting from nothing again and re-establishing trust with new roots of trust and generating all new keys and certificates for everything down the trust paths.

‍

In the past, establishing the root of trust would likely be done through a key signing ceremony (also called a key signing party). In this ceremony, security stakeholders come together to perform and oversee the signing of cryptographic certificates in order to ensure that the root CA private key and root certificate can be trusted. The certificate generation and signing must be run on an air-gapped computer with only the software needed to perform the cryptographic operations. Once this key and certificate generation operation has been performed, the stakeholders would need to sign off on these materials to prove that they were there during the generation process and approved of the output.

If people work remotely and companies don’t have any physical infrastructure, the strict requirements of a traditional key signing ceremony present logistical challenges. Instead, organizations can base their root of trust on public open source projects like The Update Framework (TUF).

If you like this blog, get the eBook: Securing the Software Supply Chain.

Like what you read? Share it with others.