Sigstore Code Signing for Software Supply Chain Security – InApps 2022

Securing software supply chains has been on the minds of IT executives of late. Nowhere was this more evident than at the Linux Foundation’s recent Open Source Summit (OSS).

At the event, Chris Wright, senior vice president and Chief Technology Officer of Red Hat discussed Sigstore, a relatively new digital signing security method for securing software supply chains.

“The answer to securing software supply chains lies in digitally-signing the various artifacts that comprise applications, from binaries and containers to aggregated files (like tarballs) and software-bills-of-materials (SBOM),” wrote Luke Hinds, Security Engineering Lead in the Office of the CTO at Red Hat, in a blog post.

Presidential Order on Cybersecurity

Sigstore is especially important in light of the President’s Executive Order on cybersecurity issued in May, section four of which calls for “Enhancing Software Supply Chain Security.”

Sigstore offers a method to enhance security for software supply chains in an open, transparent and accessible manner, Wright said in a keynote at the OSS event. The technology comes out of an open source project originally prototyped at Red Hat that is now under the auspices of the Linux Foundation, with backing from Red Hat, Google and others.

Code signing has long been an important part of securing the software supply chain, said Sandy Carielli, an analyst at Forrester Research.

“Sigstore helps democratize code signing and make it easier to sign and verify code,” she told InApps. “Having a code signing project that is free and easy is certainly welcome, and it will address some of the software supply chain risks we see today.”

However, software supply chain security is a complex challenge that will not be solved by any single tool, Carielli said.

“Code signing is critical, and so are other tools and processes, like software bill of materials or SBOM,” she said. “Also, keep in mind that signing and verification just confirms that the library is the one you think you are getting — it doesn’t guarantee that the library itself isn’t malicious. So welcome Sigstore as one piece of a much larger puzzle.”

According to the President’s order, “The term ‘Software Bill of Materials’ or ‘SBOM’ means a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components.  The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities.”

Make Software Signing Ubiquitous

Meanwhile, “Sigstore aims to make software signing ubiquitous in much the same way that Let’s Encrypt made X.509 certificates for TLS [Transport Layer Security] commonplace,” he said, noting that before Let’s Encrypt, you would have seen HTTPS in your address bar only when you were shopping on e-commerce sites.

“That’s because there were billions of dollars at stake and it was no coincidence that there was a higher level of security required,” Wright said. “Online shoppers needed confidence that their credit card numbers weren’t going to be stolen. The technology worked. Now, given how accessible the certificates are, nearly every site runs HTTPS and is by definition more secure.”

This is the model Sigstore follows. Sigstore is intended to make cryptographic signing easier and available to all, Wright said. And, most importantly, to make it available at no cost. While many digital signing systems are good, they are also expensive and “don’t fit the model of open source’s innovation engine,” Hinds said in his post.

However, Sigstore removes the cryptographic burden and makes digital signing accessible, Wright said. “This happens by enabling developers to use an email address via the OpenID Connect protocol as a pre-existing identifier,” he noted. “The project also produces an open but immutable activity log for anyone to audit. To offer all of these capabilities and become a widely used free service, we need to establish trust.”

“Sigstore is designed with open source maintainers, for open source maintainers,” wrote Kim Lewandowski and Dan Lorenc of the Google Open Source Security Team in a blog post from March. Lorenc has since left Google to found a stealth startup in the software supply chain security space. “We understand long-term key management is hard, so we’ve taken a unique approach of issuing short-lived certificates based on OpenID Connect grants.”

By building on a clever composition of existing technologies that respect privacy and work at scale, Sigstore is the core infrastructure needed to solve the fundamental problem of ensuring the security of the open source software ecosystem without undermining the open, decentralized collaboration that makes it work, said Mike Malone, CEO of Smallstep, in the Google team’s post.

Transparency, Partnership and Trust

Transparency, partnership and trust are three important words that should be familiar to everyone who’s involved in open source communities and software development, Wright said. “The trust we place in our digital infrastructure should be proportional to how trustworthy and transparent that infrastructure is,” he said.

Moreover, “How do you secure a supply chain for a product that has no physical form, no box to lock in, is created in an environment where anyone can contribute to the open source community, which is a group of individuals who, in fact, respect each other’s anonymity? You don’t necessarily have to know the other person who created the code, but you do need to trust them,” Wright said.

That said, without trust Sigstore can’t be counted on by other authorities or services to show that an individual is who they say they are or that the software produced is what it claims to be — which falls under another keyword: transparency.

“We have big plans with Sigstore and that’s where partnership comes into the picture. So far, the community counts more than 675 commits more than 465 members and 20 organizations,” Wright said. And Sigstore is still scaling up along with the subprojects Rekor, a timestamping service and transparency log, and Fulcio, a free code-signing certificate authority, he said.

However, even an application composed completely from trusted sources becomes dangerous the moment it’s not checked for new defects and security issues, both in the application itself and its underlying code dependencies, Wright said.

Project Thoth

DevSecOps practices and automated tools have evolved to make this more manageable, but Red Hat hopes to do even better, he said.

The goal of Red Hat’s AI-based DevSecOps initiative is to ease this burden using AI-enabled automation, and best practices for software development and lifecycle management Wright said. DevSecOps tools plug into CI/CD systems to help developers define software stacks in a predictable manner. And they also automate the task of ongoing maintenance, stack optimization updates to new versions, tests and security fixes.

“These automation tools are backed by a guidance learned from actual developer use, community interactions and automated testing that improves its behavior over time,” Wright said. “Our initial investment in this concept is an open source service called Project Thoth.”

Project Thoth uses AI to analyze and recommend software stacks for Python applications with an initial focus on data science use cases.

“Data scientists can use Thoth through a JupyterLab plugin that integrates the guidance directly into their preferred tool as well as automation integrated into the build pipelines,” Wright said. “This allows data scientists to focus on the actual data science without being burdened by the complexities and security challenges of the underlying software stacks.”