Implement digital signatures to verify software supply chain integrity

The escalating rise of attacks on the software supply chain means organizations must prioritize efforts to protect their entire software supply chain. An attack on an organization's software supply chain can have significant consequences on its financial situation and reputation, underscoring the importance of working to protect every component of your supply chain process. The software industry is coalescing around best practices to address supply chain attacks, including the Secure Software Development Framework (SSDF) and Supply chain Levels for Software Artifacts (SLSA). It also continues to improve tooling to address those best practices.

[ Check out Red Hat Portfolio Architecture Center for a wide variety of reference architectures you can use. ]

This article shows a practical example of using digital signatures in the software supply chain. Digital signatures provide a way to verify the integrity of a piece of software and, hopefully, its provenance. Digital signatures have been widely deployed in the software industry for decades. The difference now is organizations need to use these tools at a scale and with a deeper level of integration than they ever have.

You can better protect your supply chains and software products by digitally signing your source code, dependencies, and build process. This example leverages some of Red Hat's product portfolio and great upstream projects like sigstore to digitally sign a pipeline.

Example DevSecOps pattern

The diagram below is an example of how Red Hat customers can leverage DevSecOps in their build process by adding digital signing capabilities.

Image

The pattern involves:

• Pushing source code into a repository: Tools like gitsign provide keyless git commit signing.
• Running the software build process in the Red Hat OpenShift Pipeline tool: Red Hat now provides Tekton Chains, which provide the capability to sign the execution of tasks in the pipeline and its artifacts. Tekton Chains is in tech preview but should soon be generally available.
• Leveraging cosign to generate keys and use them to sign output images and artifacts: Cosign can be integrated with key management systems (KMS) and hardware tokens. Cosign can also be used with OpenID Connect (OIDC) for keyless signing.
• Storing images and signatures: Red Hat Quay registry supports the OCI Artifact standard and can store both signed output images and their signatures.
• Policy-based enforcement: Along with signed images is the need for a policy engine to enforce policies disallowing the use of non-signed images. Red Hat Advanced Cluster Security (RHACS) is a policy engine that can manage how OpenShift consumes signed images.

[ Learn more about how to automate DevSecOps in OpenShift. ]

A demo pattern

Below is an example of a completed OpenShift Pipeline reflecting the DevSecOps patterns mentioned above with a sample pet clinic application. It runs through the steps explained in the pattern with digital signing capabilities integrated.

Image

The OpenShift DevSecOps pipeline adds a step to sign the output image. You can leverage cosign to generate keys and sign the output images as part of the build pipeline. The pipeline still leverages RHACS to handle other pipeline security functions. RHACS will scan for vulnerabilities and then check for policy violations and configuration issues.

Image

Since this demonstration leverages Tekton Chains, you can sign every execution of the tasks that make up the pipeline. This approach certifies the integrity of the build process from unexpected changes. The above is a manifest for the unit-tests task from the pipeline. Tekton Chains takes a snapshot of the task runs. It then converts the snapshot to one or more standard payload formats. For this example, Tekton Chains annotates the task with the generated payload and payload signature.

This manifest shows the generated payload under chains.tekton.dev/payload-taskrun-8a7e88c3-0643-4010-a3db-20745a791eed. The payload signature is visible under chains.tekton.dev/signature-taskrun-8a7e88c3-0643-4010-a3db-20745a791eed.

Image

[ For more on OpenShift and Tekton, download the complimentary eBook Getting GitOps. ]

Consider what's different in the Quay registry. Notice the image tag (latest) and a signature tag (with a digest). A cosign reference on the image (at the bottom of the image) points to the signature's tag (digest) value. Quay helps streamline the process by storing the signatures in the same place as the images.

Image

Finally, enforcement is necessary to make sure only signed images are used. Add the cosign keys into RHACS. Create policies around running signed and unsigned images in OpenShift.

Image

The figure above shows a violation that occurred because of a deployment that was not signed with the key.

You can find the demo code in our GitHub repository if you would like to test this process on OpenShift 4.10 clusters.

Wrap up

Best practices like SLSA are level-based as they acknowledge the difficulty in creating a secure end-to-end software supply chain. The tooling described above can help you start the journey to protecting your software supply chain.

[ Check out Automation at the edge: 7 industry use cases and examples ]