Sigstore, the Swiss army knife of signing and attestation — Kernwerk
Sigstore, the Swiss army knife of signing and attestation<br>Jul 29, 2026
Quantization: how much precision do you actually need?<br>Jul 22, 2026
Shipping confidential models to edge devices<br>Jul 20, 2026
Sigstore, the Swiss army knife of signing and attestation
July 29, 2026 · by Pierre Dubouilh
[Sigstore] is a Linux Foundation project for signing and verifying software artifacts. It came out of the container-supply-chain world and is now the de-facto answer to “how do I sign a build artifact in 2026”.
Their signing tool [Cosign] allows you to sign Kubernetes releases, as well as npm and PyPI packages, or any other artifact.
And [Rekor] is Sigstore’s transparency log: an append-only, Merkle-tree-backed public record of signing events, same design family as Certificate Transparency. Cosign automatically uploads signing events to the log, and anyone can look an artifact up later on.
Sigstore is a solid piece of software, and we decided to use it in our signing and attestation solution.
This post is a practical tour of Sigstore. We will then see how we integrated it in our embedded signing pipeline in 150 lines of freestanding C, and then look at Sigstore’s future in the Post Quantum world.
Signing without a key
The remarkable thing about cosign is that its normal mode involves no signing key of yours at all . You sign with your identity:
$ cosign sign-blob --bundle model.bundle model.enc<br>Generating ephemeral keys...<br>Retrieving signed certificate...<br># your browser opens; log in with Google/GitHub/Microsoft
Under the hood: cosign generates an ephemeral key pair on the spot, and Fulcio, Sigstore’s certificate authority, issues a short-lived certificate binding that key to the OIDC identity you just logged in with.
The ephemeral private key is used once and thrown away. Verification then pins an identity, not a key:
$ cosign verify-blob --bundle model.bundle \<br>--certificate-identity [email protected] \<br>--certificate-oidc-issuer https://accounts.google.com \<br>model.enc<br>Verified OK
Container images work the same way cosign sign ghcr.io/you/image@sha256:..., with the signature stored next to the image in the registry, which is the form you’ve most likely already met in the wild.
Why we decided to use cosign
Cosign speaks natively to cloud KMS backends and hardware tokens . Whether you use a KMS from AWS, GCP, Azure, HashiCorp Vault, or a local PKCS#11 HSM, you can use cosign to sign your artifacts natively.
This is a fantastic feature for us, as it makes our model image encryption service really cloud-agnostic.
Our thin verifier
In our system, two kinds of artifacts carry cosign signatures:
The encrypted model is signed once on the build host, and the kernel module verifies that signature before it will even talk to the TEE about decrypting it.
Every binary allowed to read the model is signed too. The decrypted model lives in a kernel-owned memory region, and the kernel module verifies the calling program’s signature on every open. No valid signature, no mapping, even for a root user.
Technically, cosign’s wire format is very straightforward: the .sig file is base64 of a DER ECDSA-Sig-Value{r,s}, over SHA-256 of the blob, P-256 only (the only key type cosign generates). Because of its simple design, we were able to implement a cosign verifier in 150 lines of C.
We wrote [cosign-verify] for this task. It only performs the verification logic cosign is doing internally. Because we live in a kernel module, we needed to keep this library as thin as possible.
For the cryptographic part, we partially vendored (2 files) from the Android’s crypto library (libmincrypt), so that we could avoid any external dependencies. This library is embedded in the Android bootloader to verify OTA update signatures.
Cryptographic agility and the post-quantum world
I first heard the expression “cryptographic agility” fairly recently, at the Confidential Computing Summit in San Francisco in June 2026, and I was mildly surprised by the term.
The post-quantum world is coming closer, and we need to be agile to adapt to future threats, by preparing our libraries to support new cryptographic algorithms and tooling.
Thankfully, Sigstore is working on post-quantum support, and support will come as soon as stabilized cryptographic primitives are available in Go.
We will then be able to support PQC blob signatures natively in cosign. We will just have to adapt our verifier to support the new format when it becomes available.
This is part of a series on shipping confidential models to edge devices — the first post covers the full system: encrypted at rest, decrypted only inside a TEE, readable only by signed code, even against root.