Linux Foundation’s Sigstore Aims to Secure Software Supply Chains

As of yet, there is no standardization for security software supply chains. And to make matters even worse, most cryptographic signature tools don’t get used, because they’re either too cumbersome to work with or too confusing. The job of the developer is already challenging enough. Without easy-to-use tools to digitally sign their code, few developers are going to bother.

With the help of Red Hat, Google, and Purdue University, the Linux Foundation has launched a digital signing project, called sigstore, that could possibly eliminate so many of these issues that stem from having to secure open source code.

With this service, developers can digitally sign release files, container images, and binaries. Once an artifact is signed, the signing record is retained in a tamper-proof public log. The sigstore will be free to use by all developers and software providers.

The sigstore project “enables all open source communities to sign their software and combines provenance, integrity and discoverability to create a transparent and auditable software supply chain,” said Luke Harris, Red Hat security engineering lead in the office of the CTO, in a statement.

Once the sigstore is in place, it could effectively remove any security-related barrier to entry for open source software. With software signed by the service, COOs and CTOs can trust the software they are deploying won’t result in another Solarwinds disaster.

Think about the implications.

How It Works

This new (free) service is like Let’s Encrypt (another Linux Foundation project), but for code signing. The sigstore will provide free certificates and the necessary tools to automate and verify signatures for source code. This new service works like this:

• A developer generates ephemeral key pairs for their software, using the sigstore client.
• The sigstore PKI provides a signing certificate (upon a successful OpenID connect grant).
• The certificate is recorded into a certificate transparency log.
• The transparency log introduces a trust root to the users OpenID account.
• With the signing complete, the short-term keys can be discarded.

At this point, there’s a certificate of trust associated with the software.

As of the first release, the sigstore is targeting generic release artifacts such as tarballs, binaries, and container images. With later releases, the sigstore will explore other types of artifacts such as jars, manifests, and Software Bill of Materials (SBOM).

The only personal information required to use sigstore will be an OpenID Connect grant (which only includes the user’s email address); so sigstore will not be accessing your contacts, cloud drives, calendars, or any other bits of information.

Sigstore users can either use the service or even deploy a “rekor” server (which manages a “tamper-resistant ledger”) in-house (we’ll go through this in a later tutorial), which has a pluggable PKI and currently supports:

• GPG
• X509
• Minisign

With a rekor server, you can customize manifest schema, so you can get rekor to work with nearly any values you require (find out more about rekor pluggable types).

Check back here in early April for a tutorial on how to set up the rekor server.