How Safe Are Your Software Dependencies?
An exploration into how keyless signing is revolutionizing software supply chain security
If you’re a developer, the chances are high that you routinely download and integrate packages from various package managers without much thought. But the stakes are higher than you might realize. Major enterprises have fallen victim to devastating attacks — think SolarWinds and the Log4j vulnerability — that have cost hundreds of millions in damages and eroded public trust.As software supply chain attacks escalate, it’s not just big enterprises that are at risk; every developer and organization is a potential target. It’s time to rethink how we secure our software supply chains, and keyless signing could be the game-changer we’ve been waiting for.
In this post, you’ll learn how innovative keyless signing techniques can help fortify software supply chain security. We’ll analyze the gaps in current practices and explain how approaches like Sigstore and OpenPubKey are fundamentally improving protection for modern software delivery.
Gaps in Traditional Software Supply Chain Security
Inadequate verification mechanisms
Traditional scanning tools often fail to detect injected vulnerabilities, as seen in SolarWinds.
These tools frequently cannot validate the integrity and authenticity of dependencies.
Unclear provenance trails
Breaches like Kaseya revealed how unclear code provenance enables malicious distribution.
Current practices generally lack end-to-end audit trails to verify code integrity.
Inconsistent key management
Manual key management is prone to human errors that can allow unauthorized access.
Inconsistent practices create vulnerabilities.
If any of these issues resonate with your current software supply chain practices, know that you’re not alone. In the next section we delve into how Keyless Security directly addresses each of these challenges.
The Keyless Security Approach
Keyless security eliminates risky manual key management by:
Automating identity verification to avoid human error
Enabling clear provenance tracing for integrity
Standardizing protocols for consistent security
This approach addresses the gaps of traditional practices. Let’s explore how projects like Sigstore and OpenPubKey enable Keyless Signing.
How does Sigstore enable keyless signing and verification?
Sigstore has been the pioneer in this space, particularly beneficial for those engaged in open source projects. It offers open source software and ‘public good’ infrastructure which anyone can leverage to enable keyless signing with out needing to build private infrastructure. The components that enable this include :
Cosign (Container Signing) — an open source CLI for cryptographic signing and verification of release artifacts (binaries, container images etc..) without keys
Fulcio — a free to use certificate authority that generates identity certificates
Rekor — an immutable tamper resistant publicly accessible ledger of metadata generated within a software projects supply chain
Integrations — with public registries like DockerHub, GitHub etc that enable developers to setup Continuous Integration pipelines with Sigstore signing and verification.
Together these components automate signing and validation to eliminate risky manual key management.
Keyless signing workflow
Let’s try to understand the signing workflow better by signing a nuget package file (this could be any file that you want to distribute) :
Use cosign cli to sign the file ( see step 1 above) :
###
# LLMSharp.OpenAi.Tokenizer.1.0.0.nupkg : is the file I want to sign
# cosign.bundle : is the bundle with the signing metadata (signature and certificate info)
###
cosign sign-blob LLMSharp.OpenAi.Tokenizer.1.0.0.nupkg -bundle cosign.bundle
Fulcio is the Certificate Authority ( part of the public good infrastructure ) receives the request and generates a short-lived certificate for signing the file by authenticating the requested user ( See Steps 2, 3 and 4 above)
# Browser will open asking user to sign
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=oswaiXwTwoWe_bNhu6LkDAw3xwbML2HR6ym3I8HwGXo&code_challenge_method=S256&nonce=2WzmV40BWX5m5kNE1W7aNAawOHX&redirect_uri=http%3A%2F%2Flocalhost%3A63846%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=2WzmV3xQOvz96HZHD61NTjnW2Lo
# after successful authentication a short lived cert
# with a verified Signed Certificate Timestamp (SCT) is generated
Successfully verified SCT...
The generated short lived certificate is returned to cosign for signing the file ( see Step 5 ) , Fulcio will also log the metadata of the certificate and signing details to an immutable transparency log called Rekor (which is also part of the public good infrastructure)
# using ephemeral certificate:
-----BEGIN CERTIFICATE-----
MIIC2jCCAmCgAwIBAgIUaJwtM7MY2Ac9Uk5FGLktYYBgvOAwCgYIKoZIzj0EAwMw
NzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRl ...
# logged an entry to Rekor
tlog entry created with index: 44179994
cosign will use this certificate for signing the file and generate the bundle file which the developer will distribute it for consumers.
# signing using ephemeral certificate:
-----BEGIN CERTIFICATE-----
MIIC2jCCAmCgAwIBAgIUaJwtM7MY2Ac9Uk5FGLktYYBgvOAwCgYIKoZIzj0EAwMw
NzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRl ...
# Wrote bundle to file cosign.bundle
MEUCIApidAxHL2UCPbtmnK+Lk+8AZ5KSJm3w/A6IOZsHSCQmAiE....
Keyless verification workflow
Verification is pretty straight forward, as shown in the workflow below
Using Cosign CLI developer runs ‘verify-blob’ command against the signed file. Cosign validates the public key bound to the certificate that signed the file with the log information in the Rekor transparency log. It validates this by ensuring the timestamp in the immutable log falls in the short duration that the certificate was issued and used.
###
# verify-blob requires following inputs :
# 1. actual signed file
# 2. bundle file generated during signing workflow
# 3. user/developer identity that was used for signing
# 4. oidc issuer ( in this specific example, github)
###
cosign verify-blob LLMSharp.OpenAi.Tokenizer.1.0.0.nupkg
--bundle cosign.bundle
--certificate-identity=veerash@vabc.com
--certificate-oidc-issuer=https://github.com/login/oauth
# verification result
Verified OK
The Sigstore signing and verification workflows encapsulate a holistic approach which substantially alleviates the risks tied to manual key management and ambiguous provenance trails, showcasing a robust example of keyless security in software supply chains.
OpenPubKey approach
In this section we will briefly touch upon OpenPubKey a new initiative spearheaded by Bastion Zero and Docker, backed by Linux Foundation. I will not delve much deeper into it’s workflow as the current reference implementation is still work in progress ( as of Oct 2023).
Some high level workflow details :
How does the protocol work? OpenPubKey augments OIDC protocol on the client side with a clever usage of ‘nonce’ that transforms the ID Token into a certificate that cryptographically binds an OIDC user identity to a public key, enabling the secure signing and verification of software artifacts.
How is the nonce generated? OpenPubKey creates a unique nonce by hashing the user’s public key + random value ( which the protocol terms as Client Instance Claims). This hashed value is then included in the authentication request sent to the OIDC provider. When the OIDC provider responds with a signed ID Token containing the nonce, it essentially transforms that ID Token into a cryptographic certificate bound to the user’s identity.
Is it a replacement for Sigstore? Not really, it is not a holistic end-end solution like Sigstore. It tries to reduce (look at open questions)dependency on centralized components like a Certificate Authority and Transparency Log by relying on a decentralized component like OIDC provider. The team implementing OpenPubKey claims “
OpenPubkey cannot really be compared to Sigstore. Sigstore is an end-to-end artifact signing solution, whereas OpenPubkey only binds public keys to OIDC identities for use as part of a larger signing solution. OpenPubkey is complementary to Sigstore
”.Isn’t OIDC provider a single point of failure? OpenPubKey allows an MFA-Cosigner that uses Multi-Factor Authentication (MFA) for additional, independent identity verification. This dual-layer system ensures robust security, even if one of its components — either the OpenID Provider or the MFA-Cosigner — is compromised.
What are some open questions? As the verification process relies on the keys used by Identity providers which are rotated frequently and there is no guarantee on the integrity of these keys once they are rotated out, having a centralized authority to keep track of these keys across various identity providers and having a MFA-Cosigner seems to be mandatory rather than optional.
While the approach used by OpenPubKey appears much simpler we will have to wait and watch on how a concrete implementation addresses some of the major open questions that we discussed. This is definitely a space to watch given the major players involved.
As of today, my recommendation is to still go with the comprehensive and well vetted approach of Sigstore for enabling Keyless signing.
The Path Forward
As software supply chain attacks proliferate, forward-looking solutions like SigStore and OpenPubKey are critical for security and integrity. Evaluating and piloting these tools isn’t just an exercise; it’s a responsibility for anyone involved in software development. You’re not just protecting your project; you’re contributing to a safer, more resilient software ecosystem.
The journey towards more secure and resilient supply chains begins with learning about and pioneering new methodologies. Will you lead the way?
References
Solarwinds : https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack
Kaseya : https://www.upguard.com/blog/how-did-kaseya-get-hacked
Sigstore :
https://www.sigstore.dev/
Cosign : https://github.com/sigstore/cosign
Fulcio : https://github.com/sigstore/fulcio
OpenPubKey : https://eprint.iacr.org/2023/296