Sigstore: An open answer to software supply chain trust and security

Everything starts from somewhere, and software is no different - just as physical goods have a point of origin and an associated supply chain, so does code. In today’s world, the origin story for most software applications starts, at least partially if not entirely, in an open source community. So how do you secure a supply chain for a product that has no physical form, no box to lock and is created in an environment where anyone can contribute to it?

This is the goal of sigstore, an open source project originally conceived and prototyped at Red Hat and now under the auspices of the Linux Foundation with backing from Red Hat, Google and other IT leaders. Sigstore offers a method to better secure software supply chains in an open, transparent and accessible manner. The need for a project like sigstore is underscored by the recent attacks and breaches of critical digital infrastructure, both in North America and globally, leading to a U.S. presidential executive order aimed at furthering software supply chain security.

So why do we need something like sigstore, exactly? And what does sigstore do that existing technologies, built to certify and sign digital technologies, don’t?

The inaccessibility of digital signing

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). Digital signatures effectively “freeze” an object in time, indicating that in its current state it is verified to be what it says it is and that it hasn’t been altered in any way. This is great for developers who are pulling lots of various code and projects into more complicated workloads...or it would be if the process was better equipped to handle open source.

Many digital signing solutions are good at what they do, but they’re expensive and don’t fit the model of open source’s innovation engine. These two things alone would be an issue, but there’s also the matter of who holds the private key - this is exactly what it sounds like and is essentially the identification that says code came from a specific given source. In open communities, where tons of people contribute, is everyone supposed to hold a private key? Just the community leads (if they exist)? The sponsor?

This is the challenge facing the software supply chain, especially in open source: budgets are small to non-existent for digital signing tools, the software itself is changing frequently and there’s the management and securing of private keys over the life of the project’s existence. 

Enter sigstore!

Digital signing made for everyone

Sigstore aims to make software signing ubiquitous, in much the same way that Let’s Encrypt made X.509 certificates for Transport Layer Security (TLS) commonplace. Before Let’s Encrypt, you may have only seen HTTPS in your address bar for e-commerce sites; now, given how accessible the certificates are, nearly every site runs HTTPS and is, by definition, more secure. This is the model that sigstore wants to follow.

Sigstore is intended to make cryptographic signing easier - cryptography is a specialized skill, and one that the bulk of developers aren’t deeply familiar with. Sigstore removes this burden and makes it accessible by enabling developers to use an email address via the OpenID connect protocol as a preexisting identifier to sign their code. The project also produces an open but immutable activity log for accountability.

To fully offer all of these capabilities and become a widely-used, free service, we need to establish trust - literally. Trust is the root (ha!) of digital security, whether it’s web certificates or code. Without this trust, sigstore can’t be counted on by other authorities or services to accurately show that an individual is who they say they are and that the produced software is what it claims to be. 

So now we’re working to establish the Sigstore Trust Root, an effort that was kicked off by a public Key Signing party. Five community members, one of which I am honored to be, created cryptographic keys on a community livestream, which were then published to a GitHub repository and verified live by viewers. This is the foundation of the Trust Root for sigstore, and as part of our commitment to transparency and openness, the Key Holder roles will rotate through the community as we grow.

What’s next

Sigstore is still building up, along with the subprojects Rekor (a timestamping service and transparency log) and Fulcio, a free code-signing certificate authority, but we have big plans. Beyond growing the community, we’re working with the Linux Foundation to stand up a fully-staffed public service. Finally, from a Red Hat perspective, we’re exploring how to build the capabilities of sigstore into Red Hat OpenShift, via container tools and Red Hat Advanced Cluster Management for Kubernetes as a way to bring integrated and open software signing into existing application workflows.

The need for free and open digital code signing is only expected to grow. As has been said many times, every company is now a software company - this means that code isn’t just running our laptop and phones. It’s the engine behind global financial systems, healthcare advancements, modern cars and more. Even our food supply, from the tractors harvesting crops to the trucks transporting goods, is now rooted in applications and technology. Sigstore aims to make code signing as accessible and broadly available as software itself. I encourage you to check out sigstore for yourself and see where we hope to take the next generation of code security!