Software supply chain security has captured the attention of the media, the US federal government, and just about every company that builds or deploys software. As a response, several tools have been created to “secure the supply chain.” However, securing the software supply chain is larger than any one tool. The software supply chain is an interconnected set of code, build tools, and more, and so securing it requires an equally diverse toolbox of strategies.
Organizations have broken down the software supply chain in order to understand how to secure it. The Cloud Native Computing Foundation’s (CNCF) Software Supply Chain Security whitepaper lists the components of a software supply chain as:
Software supply chain security has captured the attention of the media, the US federal government, and just about every company that builds or deploys software. As a response, several tools have been created to “secure the supply chain.” However, securing the software supply chain is larger than any one tool. The software supply chain is an interconnected set of code, build tools, and more, and so securing it requires an equally diverse toolbox of strategies.
Organizations have broken down the software supply chain in order to understand how to secure it. The Cloud Native Computing Foundation’s (CNCF) Software Supply Chain Security whitepaper lists the components of a software supply chain as:
- Source code
- Materials
- Build process
- Artifacts
- Deployment.
NIST’s Secure Software Development Framework (SSDF; see our explainer!) lists the requirements for securing your supply chain as:
- Prepare the Organization
- Protect the Software
- Produce Well-Secured Software
- Respond to Vulnerabilities
Supply Chain Levels for Software Artifacts (SLSA), a framework to help organizations and projects incrementally harden their software supply chain, categorizes its controls into the following categories:
- Source
- Build
- Provenance
- Common (shared across the supply chain)
Despite these superficially different categorizations, the actual requirements for securing the supply chain described in each of these efforts have a lot of overlap. You can see the similarities by exploring some mappings between these different software supply chain security requirements produced by the CNCF, Red Hat, and here at Chainguard.
Regardless of how you divide up the software supply chain, each of these components requires multiple tools to secure. Every software supply chain is unique, and thus requires different combinations of tools to secure. These tools not only add cryptographic attestations, but also ensure that security best practices are followed at each stage of the supply chain.
The toolbox
The first tool in our software supply chain security toolbox is Sigstore. In general, Sigstore focuses on the problem of allowing various identities to make claims (“attestations”) about the supply chain. This is what SLSA refers to as “provenance” and NIST calls “protecting the software,” and covers all stages in the CNCF’s breakdown. Each of the projects within Sigstore contributes to this focus. Gitsign signs git commits, contributing to securing the source code by providing evidence that a given identity created a commit. Cosign signs (and verifies) artifacts for distribution, contributing to artifact security (or another part of “protecting the software”) by attesting that a given developer or build environment has deemed the software ready to distribute. Fulcio eliminates the need for developers to manage long-lived signing keys. While this does not map directly to any of the stated software supply chain security requirements, it makes Gitsign and Cosign easier to use, enabling widespread adoption. Rekor attests to the freshness of signatures and other metadata, while allowing for discovery of any tampering through an append-only log.
Despite the many advantages of using Sigstore, it is not a panacea for software supply chain security. Rather, it is one set of tools that can be combined with others in this space to build up a secure supply chain.
For example, The Update Framework (TUF) allows verifiers in the software supply chain to securely determine which identities should be trusted to sign each artifact, and provides protection against subtle attacks on software distribution (like distributing artifacts which were formerly valid, but have been revoked). This can coexist with Sigstore tooling by using Sigstore to connect an identity to an attestation, while using TUF to determine whether this identity should be trusted. Secure distribution with TUF contributes to securing the Artifacts in CNCF whitepaper, “Protect the Software” in NIST’s framework, and “Provenance” in SLSA.
The in-toto project also links identities to the roles they are responsible for, but for all of the steps in the software supply chain, not just distribution. in-toto allows an organization to ensure that all steps in their supply chain were performed by the proper parties before the software is distributed or run. To do so, in-toto allows supply chain managers to define all the steps that should be performed from software creation to delivery. Then, the entities that performed each step can cryptographically attest that they did so, and link this attestation to their identity. in-toto is also compatible with Sigstore. In fact in-toto attestations are the second most common attestation type in Rekor. in-toto can apply to all five stages of the CNCF whitepaper, especially the first three, as it can include metadata about any of these stages. It also contributes to “Protect the Software” for the SSDF and “Provenance” for SLSA.
Next, apko is a tool that secures the build process for OCI images by providing reproducible builds with built-in information about dependencies and versions. Reproducible builds ensure that if the code is built multiple times, it will produce the same binary each time. This allows the build to be verified by multiple, independent rebuilders. akpo contributes to “Build process” security for the CNCF, creating a build process to “Prepare the Organization” in SSDF, and the “build” stage of SLSA.
There are many more projects that provide security for specific pieces of the software supply chain. These include source code protection like branch protection, code scanning, MFA; dependency management tools like SBOMs (which apko can generate), vulnerability reports; build security such as reproducible builds and dedicated build machines; and much more. In order to secure your supply chain, you need a toolbox that consists of a combination of these projects to cover all of the steps in your supply chain.
Securing your supply chain is more complicated than finding a single tool that will solve all of your problems. It requires understanding your current software writing, building, and distribution mechanisms, and integrating security throughout this process. Luckily, there are many tools available, including some of the ones listed above, that can help with individual pieces of this problem. Here at Chainguard, public and private adoption of these existing open source solutions enables our products, like Chainguard Enforce, to ensure the security of your application’s supply chain.
For further guidance on how these and other tools fit into existing standards, review these ongoing community efforts:
