Sigstore: Roots of trust for software artifacts

By Dan Lorenc, InfoWorld |

Emerging tech dissected by technologists

For the roughly five billion people who use the internet, only a tiny fraction have any knowledge of how Transport Layer Security (TLS), digital certificates, or public keys work. Say what you will about the security perils that users still face on the internet today, but it’s pretty remarkable how well these building block protocols for trust between websites and site visitors have handled the massive scale of the internet over the last 20 years.

By contrast, the concept of software supply chain security is still relatively new. The headlines about SolarWinds and Log4j created some basic awareness of the backdoors that are created when developers use software artifacts with unknown provenance. But how do we take these same basic principles of how trust works on the internet, and apply them to establishing trust between software artifacts, and the millions of developers using them? Most software developers are still in the earliest phases of trying to understand this.

Recently, I heard Vint Cerf discuss parallels between early web public key infrastructure (PKI) and the emerging artifact signing and open source signing ecosystem. What struck me is that while much of trust on the internet was driven by influential groups like the Certification Authority Browser Forum, which galvanized the use of these protocols by baking them into browsers and operating systems. With software supply chain security, there’s no equivalent group that’s driving this. We’re all making it work in an open community way, and on foundations of open source projects.

If you want to get your bearings on the evolution of this emerging security domain, there’s no open source project with more momentum or industry coalescence than Sigstore—the software supply chain’s canonical artifact signing project. Let’s take a look at some of the principles and primitives of Sigstore, so you understand what’s under the hood the next time you see that your package manager or build system is using Sigstore’s wax seal of approval.

The web’s PKI infrastructure was designed in a way that any web certificate authority (CA) is trusted to issue certificates for any domain on the internet. Policing these certs from abuse—say, a CA issuing a cert for a domain they don’t control, like your bank’s website—is something called the Certificate Transparency framework. It’s an open blockchain framework that provides an “append-only” public ledger.

Transparency logs are critical because they give developers and security teams the ability to monitor that all the certs issued for a company’s domain name are correctly issued. This helps you detect if anyone is masquerading as your company and spoofing your traffic. The point of transparency logs is to capture those mistakes on record so you can find them later, recover from them, and mitigate the bad things.

Sigstore is an open source framework that took the Certificate Transparency framework (as well as the popular TLS framework, Let’s Encrypt) as inspiration for how to effectively solve the very similar challenges that exist for software artifact integrity in supply chain security. When we download a software artifact, how do we know who it was created by, and that it is the same artifact (and not a malicious imposter) that we are downloading? Sigstore solves this by allowing developers to securely sign software artifacts such as release files, container images, binaries, SBOMs (software bills of materials), and more. Signed materials are then stored in a tamper-resistant public transparency log.

There are three key primitives that drive Sigstore. You need all three of them together to build the whole Sigstore puzzle, but they serve different and independent purposes:

One thing that software supply chain security may ultimately have in common with TLS on the web is that most of the people who use it may not even know what’s under the hood and making it all possible. And that’s OK!

Sigstore is a nearly 10-year evolution of concepts that date back to the 2014 ACM Queue paper, Certificate Transparency: Public, Verifiable, Append-only Logs. Google’s open sourcing of Trillian (a database that uses transparency logs as a core primitive) was another big evolutionary step in 2016. Mozilla’s work around Binary Transparency shortly after got deep into the importance of “know what’s in your software” and was another huge inspiration for the project. And of course, Brandon Phillips’ introduction of Fulcio was another watershed moment for the project.

But ultimately as a developer, what you’re going to care most about with Sigstore is that you don’t have to think about it, or appreciate any of the evolutionary steps that led to its existence.

What you should care about is that Sigstore has become the default software signing method for everything from Kubernetes to language registries like NPM (JavaScript), Maven (Java), and PyPi (Python). More than one million software artifacts live in Sigstore’s Transparency Log (Rekor).

Today when you download a package from a popular registry, you are probably using Sigstore without knowing it, the same way that you no longer think about HTTPS or certs when you browse the web. And that’s the surest sign that we’re making major progress in software supply chain security.

Dan Lorenc is CEO and co-founder of Chainguard. Previously he was staff software engineer and lead for Google’s Open Source Security Team (GOSST). He has founded projects like Minikube, Skaffold, TektonCD, and Sigstore.

—

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to [email protected].

Next read this:

Copyright © 2023 IDG Communications, Inc.