This post was written with the inestimable help of Luke Hinds of the Sigstore community who heped review it and edit it.
As software supply chain security becomes increasingly important, organizations are looking for robust methods to verify the integrity and authenticity of their software components. One such approach is the use of SPDX SBOMs (Software Bill of Materials) to track and document software dependencies. Contained in it is all the relevant information that is relevant to describe in detail a given piece of software: what it contains, who built it, what its dependencies are etc. The information is reliable and useful to many different stakeholders that leverage SPDX to build and share the information in their SBOMs. But, can you trust the SBOM itself? How does on know that the SBOM has not been tampered in transit? That it really comes unaltered from the person that claims to be its author?
If an SBOM isn’t signed, it could potentially be tampered with, which may lead to inaccurate or misleading information about the software’s components. While unsigned SBOMs can still provide value, signing an SBOM enhances its trustworthiness by providing a form of guarantee that the SBOM hasn’t been modified since it was signed. A signed SBOM can be verified using the signer’s public key to ensure it originated from the correct source and hasn’t been tampered with since it was issued.
Without a signature, trust in an SBOM often relies on trusting the source of the SBOM (like a trusted server) and the transport security (like HTTPS) used when obtaining the SBOM. However, this doesn’t protect against a compromise of the server or the potential for tampering after the SBOM is generated and before it’s consumed.
In this blog post, we will explore how to sign an SPDX SBOM using Sigstore’s cosign tool, a popular open-source project that provides a secure and transparent method for signing SBOM documents.
What is Sigstore’s Cosign?
Cosign is a component of the Sigstore project, designed to facilitate the signing and verification of container images. The primary goal of Cosign is to make signatures invisible infrastructure, much like how Let’s Encrypt made TLS and SSL ubiquitous on the web.
The signing of container images ensures that the images are not tampered with, and it verifies the identity of the creators. This brings an additional layer of security and trust to the software supply chain. For instance, before deploying a container image, a system can verify the image’s signature to ensure that it’s the exact image provided by the expected creator and that it hasn’t been modified by anyone else.
But Cosign can be used with other software artifacts and blobs. It allows you to digitally sign container images, binaries, blobs, and other artifacts like an SPDX SBOM. By signing these artifacts, you can establish a verifiable trust in the integrity and provenance of your software – and your software bill of materials. By default, Cosign supports identity-based signing with ephemeral signing keys, which is what the Sigstore project recommends as this removes the need for developer-managed keys. There is also support for signing with existing keys from KMS (Key Management Service) or HSMs (Hardware Security Modules). Sigstore also supports signing identities from CI workflows, such as GitHub Actions and GitLab, which works well if CI automation is generating SBOMs as part of the build process. In all cases, you’ll have signature transparency since signing events are written to an auditable, append-only transparency log.
If you are interested in gaining a deeper understanding of how SPDX helps you document and describe the composition of your build, we just released a profile called, well, Build! The maintainers of said profile have described it in detail at our latest mini summit and in this blog post, check it out.
How does it work?
Prerequisites:
Before we get started, make sure you have the following prerequisites in place:
1. A Linux or macOS-based development environment.
2. Docker installed to build the container image.
3. An SPDX SBOM file that you want to sign.
Step 1: Install Cosign (you can use Brew or look for it in your Linux distro of choice, it’s likely packaged)
To begin, let’s install the cosign command-line tool on your machine. Follow these steps:
1. Open a terminal window.
2. Clone the cosign GitHub repository using the following command:
“`
git clone https://github.com/sigstore/cosign.git
“`
3. Navigate to the cloned repository:
“`
cd cosign
“`
4. Build and install cosign using the following command (do make sure to have the right golang version which is 1.20 iirc):
“`
make
“`
5. Verify that cosign is correctly installed by running:
“`
cosign version
“`
Step 2: Import Cosign Key
Next, we need to import your personal cosign key. This key will be used to sign the SPDX SBOM. Follow these steps:
1. Generate a new cosign key pair using the following command:
“`
cosign generate-key-pair
“`
2. Enter a passphrase when prompted. Remember this passphrase, as you’ll need it to sign artifacts in the future.
Step 3: Sign the SPDX SBOM
With cosign installed and your key imported, let’s sign the SPDX SBOM. Follow these steps:
1. Move the SPDX SBOM file to a suitable directory.
2. Open a terminal window and navigate to the directory where the SPDX SBOM is located.
3. Sign the SPDX SBOM using the following command:
“`
cosign sign -key <path_to_private_key> <spdx_sbom_file>
“`
Replace `<path_to_private_key>` with the path to your private key file, and `<spdx_sbom_file>` with the actual filename of your SPDX SBOM.
4. Enter your passphrase when prompted. Cosign will generate a signature for the SPDX SBOM and append it to the file.
Step 4: Verify the Signed SPDX SBOM
To verify the signature of the SPDX SBOM, follow these steps:
1. Open a terminal window and navigate to the directory where the signed SPDX SBOM is located.
2. Run the following command:
“`
cosign verify <spdx_sbom_file>
“`
Replace `<spdx_sbom_file>` with the actual filename of your SPDX SBOM.
3. Cosign will verify the signature against the public key embedded within the SPDX SBOM and display the verification result.
Conclusion
By following this step-by-step guide, you have learned how to sign an SPDX SBOM using Sigstore’s cosign tool. Signing your software artifacts, such as SPDX SBOMs, adds an additional layer of security and trust to your software supply chain. By leveraging the power of digital signatures, you can confidently verify the integrity and authenticity of the metadata about your software components, ensuring a safer and more reliable software ecosystem.
