Recently, there’s been a lot of noise over supply chain security because of the increase in attacks, with notable ones like SolarWinds, Dependency confusion breach, and Mimecast attack. These attacks could have been prevented with proper tools in place, yet finding the right tool for the job might be difficult as this area is hard to navigate, and most developers aren’t security experts. However, a new project was announced that might solve many problems. Its name is Sigstore, and in this article, we will look at what it does, why we need it, and how it will help us protect our software supply chain.
The need for Sigstore?
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 initially conceived and prototyped at Red Hat and now under the sponsorship of the Linux Foundation with backing from Red Hat, Google, and other IT leaders. Sigstore offers a method to secure better open, transparent, and accessible software supply chains. 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 to further software supply chain security.
What’s the need for something like Sigstore, exactly? And what does Sigstore do those existing technologies, built to certify and sign digital technologies, don’t?
The answer to securing software supply chains lies in digitally signing the various artefacts 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 pulling lots of various code and projects into more complicated workloads or if the process were better equipped to handle open-source.
Many digital signing solutions are good at what they do, but they’re expensive and don’t fit open source’s innovation engine model. These two things alone would be an issue, but there’s also the matter of who holds the private key. This is precisely what it sounds like; it is essentially the identification that says code came from a specific source. In open communities, where tons of people contribute, is everyone supposed to hold a private key? The sponsor? Does just the community lead?
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 frequently changes, and there’s the management and securing of private keys over the project’s life.
Sigstore: New era of supply chain security
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 profoundly 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 these capabilities and become a widely-used, free service, we need to establish trust — literally. Trust is the root 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 individuals are who they say they are and that the produced software is what it claims to be.
How does it work?
Sigstore in works — Photo from https://www.sigstore.dev/
As for the individual components, there are currently three main pieces:
- cosign is a container signing tool. Its responsibility is to sign containers and publish that information to registries.
- fulcio is a root CA for code signing certs. Its job is to issue code-signing certificates and embed OIDC(OpenID Connect) identity into a code-signing certificate.
- rekor is the transparency log. It’s an append-only, immutable ledger that serves as the transparent source of truth of what was signed by whom.
Closing Thoughts
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 laptops and phones. It’s the engine behind global financial systems, healthcare advancements, modern cars, and more. From the tractors harvesting crops to the trucks transporting goods, and even to our food supply, they are now all rooted in applications and technology. Sigstore aims to make code signing accessible and broadly available as the software itself.
About the Author:
Vinoth is a cybersecurity professional by heart with over two decades of experience in Information Technology and Cybersecurity. He is an Australian Computer Society (ACS) Senior Certified Professional in Cybersecurity and holds various industry-leading cybersecurity credentials. Vinoth loves to write about the latest cybersecurity happenings and blockchain-related articles.
