↓ Skip to main content
Le Site de François
  1. Index/

Sigstore

Supply-Chain Security Signing Oci Pki Oidc Cncf

Sigstore is an OpenSSF project, initiated by Google, Red Hat, and Purdue University, that provides a free public-good infrastructure for cryptographically signing software artifacts — container images, binaries, SBOMs, attestations — without the operational burden of managing long-lived private keys. Its founding insight is that the two hardest problems in code signing are key management (generating, protecting, distributing, rotating, and revoking signing keys across thousands of developers and CI pipelines) and signature discoverability (how does a verifier find and trust the correct public key for an artifact it has never seen before). Sigstore solves both by eliminating long-lived keys entirely: every signing operation generates a fresh ephemeral key pair, uses it once, discards the private key, and records the event in a public transparency log — replacing “do you trust this key?” with “do you trust this identity at this moment in time?”.

Sigstore’s architecture consists of four components. Fulcio is the certificate authority: when a developer or CI pipeline wants to sign, it first authenticates to an OIDC provider (Google, GitHub, Microsoft — or any provider Fulcio trusts) and presents the resulting ID token to Fulcio. Fulcio verifies the token, extracts the identity claim (a GitHub Actions workflow path like https://github.com/org/repo/.github/workflows/release.yaml@refs/heads/main, or an email address), generates an ephemeral key pair, issues a short-lived X.509 certificate (valid for approximately 10 minutes) binding the public key to that identity, and logs the certificate to a certificate transparency log. The private key exists only in memory for the duration of the signing operation and is then discarded. Rekor is the signature transparency log: every signing event (the artifact digest, the signature, and the Fulcio certificate) is appended as an immutable entry in a Merkle-tree-backed log, and Rekor returns a Signed Entry Timestamp (SET) — a countersigned inclusion proof that the entry was logged at a specific time. The SET is the critical artifact that proves the signature was produced while the Fulcio certificate was valid, enabling verification long after the 10-minute certificate has expired. cosign is the primary client tool: cosign sign orchestrates the full flow (OIDC authentication → Fulcio certificate → sign → Rekor log → push signature to OCI registry as a referrer), and cosign verify fetches the signature, Rekor entry, and Fulcio certificate and verifies the complete chain. TUF (The Update Framework) distributes Sigstore’s root of trust — Fulcio’s root CA certificate and Rekor’s public key — securely to clients, protecting against key substitution attacks on the trust anchor itself.

Sigstore integrates throughout the supply chain stack in this glossary. Signatures and SLSA provenance attestations produced by cosign are stored as OCI referrers alongside container images, discoverable via the referrers API and fetchable by ORAS. Kubernetes admission controllers (Policy Controller from Sigstore, Kyverno with cosign support) can enforce that all images admitted to a cluster carry a valid Sigstore signature from an approved identity — a GitHub Actions workflow in a specific repository, a specific CI platform’s OIDC subject — before the image runs. SBOM documents and VEX assertions are signed with cosign and attached as referrers, so the entire supply chain metadata set (signature + SBOM + VEX + SLSA provenance) travels with the image in the registry. gitsign brings the same keyless model to Git commit signing, replacing long-lived GPG keys with OIDC-bound ephemeral certificates recorded in Rekor — every git commit --gpg-sign becomes a Rekor entry that can be verified years later without the signer maintaining a key. For private or air-gapped deployments, all Sigstore components (Fulcio, Rekor, cosign) can be self-hosted, with custom OIDC providers and private trust roots — enabling the same keyless signing model in environments that cannot use the public-good infrastructure. The PQC transition for Sigstore requires migrating Fulcio’s root CA to ML-DSA (so that the short-lived certificates it issues carry quantum-safe signatures) and Rekor’s signing key to ML-DSA (so that SETs remain unforgeable); the cosign and Sigstore library ecosystem will follow OpenSSL 3.4+ and Go’s PQC library support.

Related

OpenPGP / GPG

Cryptography Security Signing Pki Supply-Chain Email
OpenPGP is an open standard for encryption and digital signatures of arbitrary data, defined in RFC 4880 (2007) and substantially revised in RFC 9580 (2024, adding Ed25519, X25519, and modern AEAD encryption). GnuPG (GPG) is the dominant open-source implementation, maintained by Werner Koch and the GnuPG project, and the tool most users interact with. OpenPGP predates the PKI/CA model and takes a fundamentally different approach to trust: rather than a hierarchy of certificate authorities that users must trust transitively, OpenPGP uses a Web of Trust in which individual users sign each other’s public keys, and trust is established through chains of personal endorsements. In the Web of Trust model, Alice trusts Bob’s key because she verified it in person and signed it; Carol trusts Bob’s key because Alice (whom Carol trusts) signed it. This decentralised, peer-to-peer trust model made sense for email encryption between individuals who could meet at key-signing parties, but does not scale to automated infrastructure verification, which is why OpenPGP’s role in modern infrastructure is primarily supply chain signing — package repositories, Git commits, and release artifacts — rather than interactive authentication.

Kata Containers

Containers Security Virtualization Kubernetes Cncf Oci Runtime
Kata Containers is an Open Infrastructure Foundation (OpenInfra Foundation) project that replaces the Linux namespace and cgroup isolation of a conventional container runtime with a full VM boundary, while remaining entirely compatible with the OCI runtime specification and the Kubernetes CRI. From the perspective of containerd, CRI-O, or the Kubernetes kubelet, a Kata pod is indistinguishable from a runc or crun pod — the same API calls, the same lifecycle verbs, the same pod spec — but instead of calling clone() to create a new namespace, Kata starts a lightweight virtual machine. The workload runs inside that VM with its own kernel, its own device model, and a hardware-enforced isolation boundary between itself and the host kernel. The premise is that Linux namespaces, while convenient, share the same kernel as the host: a kernel vulnerability exploitable from inside a container can affect the host and every other container running on the same node. A VM boundary means that even a full guest kernel compromise cannot directly affect the host.

OCI Referrers API

Containers Oci Supply-Chain Registry Security Standards
OCI Referrers is a mechanism introduced in the OCI Image and Distribution Specification v1.1 (finalised 2024) that allows arbitrary artifacts — signatures, SBOMs, vulnerability scan reports, attestations, provenance documents — to be attached to an existing image in a registry without modifying the image itself and without requiring out-of-band storage or tag conventions. The attachment is expressed through a subject field added to any OCI manifest: a descriptor pointing to the digest of the target image. The registry then indexes these relationships, and the referrers API makes them discoverable.