Why we’re excited about the Sigstore general availability

Sigstore is a powerful new technology for signing, verifying, and protecting software supply chains, and we’re very excited by today’s general availability announcement.

Sigstore takes a new approach to solving these problems, and so figuring out exactly what it does and how to use it in your projects can be a bit tricky. This post will go over what you can do with Sigstore and GitHub Actions today, as well as preview the work we’re doing to integrate Sigstore with npm to unlock a new security capability: verifiably linking a npm package back to its source code and build instructions.

I told you we’re excited! Let’s jump in.

Sigstore and GitHub Actions, today

The first thing people do to secure their builds is to sign them, so you can detect if it’s been tampered with between when the build finished and when you’re about to run it. This often requires managing a private key, including generating it correctly, keeping it a secret, and rotating it over time. At best this is a hassle, and at worst it’s a roadblock for folks who don’t have experience in this area. As a result, builds aren’t signed nearly as often as they should be.

When you’re building in a cloud CI/CD provider that supports OIDC tokens, like GitHub Actions, Sigstore can generate a signing certificate for your build without having to maintain a private key. Sigstore calls this keyless signing, and it’s a fantastic example of lowering the barrier to entry so more projects can sign their builds. In fact, this keyless signing is already in use for Kubernetes as well as CPython releases.

To illustrate how to do this, last year we wrote about how to use Sigstore’s cosign to sign container images built in GitHub Actions. While cosign sign assumes your build is a container image, you can also use cosign sign-blob on any type of build output.

These are all things you could already do with Sigstore on GitHub Actions, but general availability is an exciting milestone in terms of maturity: the components have all reached a 1.0+ release, the APIs are stable, and the public servers now have a SLO and a 24/7 on-call rotation. This release is a collaboration across several organizations, and GitHub has directly supported it by contributing to both the development of the Sigstore code as well as the on-call rotation for the servers.

Linking npm packages to their source repository and build instructions

When you’re looking at a npm package today, there’s limited information available about where that package came from. Was it built on a laptop, or in an ephemeral environment with network isolation? Users can optionally include a link to a source repository, but that information isn’t verified, and doesn’t include the specific commit a given package version came from.

Having this information available in a verifiable way is a huge step forward for end-to-end supply chain security—whether you’re doing day-to-day vulnerability management or trying to quickly trace down affected versions during a security incident.

Earlier we mentioned the signing certificate that’s part of Sigstore’s keyless signing. Besides a signature over the bytes of the build, Sigstore encodes other information from the OIDC token into the signing certificate it returns to you, including the path to the repository, the specific commit of the build, and a link to the file that contains the build instructions.

This signing certificate with attributes from the OIDC token enables an important security capability for the npm ecosystem: the ability to verifiably link packages back to their source repository and build instructions.

While the Sigstore general availability is an important milestone towards this goal, we have a bit further to go. We’re continuing to add support for this use case to Sigstore libraries. We’re working with several cloud CI/CD providers to provide OIDC tokens with the required information, so this capability is available to you from a variety of vendors. Because the npm registry serves billions of daily downloads, it will cache this information from public Sigstore servers and make it available via the website, API, and CLI tools. Users can verify this data with Sigstore public keys, as well as querying Sigstore servers directly if they wish.

We’re continuing to work on making this available to all npm users, so stay tuned!

Written by

Zachary Steindler

@steiza

Principal Software Engineer, GitHub