Sigstore : signature keyless pour la supply chain

20 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 16 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Sigstore est l'écosystème open source qui permet de signer un artefact logiciel sans posséder de clé privée à long terme : vous prouvez votre identité auprès d'un fournisseur OIDC (OpenID Connect, le protocole derrière les boutons « Se connecter avec GitHub » ou « avec Google »), une autorité vous délivre un certificat valable une dizaine de minutes, et la signature est inscrite dans un journal public. Cette leçon s'adresse à un DevOps qui doit comprendre l'ensemble avant d'utiliser Cosign : elle présente les quatre briques, le trajet d'une signature, et ce que la signature prouve, ou non.

Elle matérialise les exigences de provenance et d'intégrité des livrables du référentiel Socle DevSecOps. Les leçons suivantes détaillent les briques : l'autorité de certificats Fulcio, puis le journal de transparence Rekor, et enfin l'outil qui orchestre le tout, Cosign.

Ce que vous allez apprendre

Expliquer pourquoi une clé de signature longue durée est un fardeau opérationnel, et comment un certificat éphémère le supprime.
Décrire le trajet d'une signature keyless, de l'authentification OIDC à l'inscription dans Rekor.
Distinguer les quatre briques : Fulcio, Rekor, Cosign et gitsign.
Choisir l'outil adapté à ce qu'on signe, et reconnaître ce qui change en CI/CD.
Énoncer ce que la signature garantit (authenticité, intégrité, non-répudiation, horodatage) et ce qu'elle ne garantit pas (qualité du code, intentions du signataire, sécurité du build).

Pourquoi signer sans clé longue durée ?

Une clé de signature classique coûte cher à garder en bon état. Il faut la générer (RSA, ECDSA), protéger la clé privée (HSM, KMS, Vault), distribuer la clé publique aux consommateurs, la renouveler (rotation), la révoquer si elle fuit, et enfin prouver que la clé appartient bien à l'équipe. Chaque étape est une occasion d'erreur ou de compromission, et une clé volée permet de signer en votre nom jusqu'à sa révocation.

Sigstore supprime ces étapes avec des certificats éphémères, valables une dizaine de minutes. La clé privée associée n'existe que le temps de la signature, puis elle est détruite : il n'y a plus rien à voler ni à faire tourner. Le schéma montre la difficulté que cela crée : une fois le certificat expiré, rien ne prouve à lui seul que la signature a été créée pendant sa validité.

Source · SVG

La réponse est le journal de transparence Rekor : la signature y est enregistrée au moment de sa création, avec un horodatage et une preuve d'inclusion. On peut donc la vérifier longtemps après l'expiration du certificat. Le schéma montre la même chronologie une fois Rekor ajouté, avec l'horodatage que signe le journal Rekor v1 (le signed entry timestamp, ou SET) ; sur l'instance publique, une autorité d'horodatage (TSA) séparée le complète par défaut, comme l'explique l'étape 4 de la signature keyless plus bas.

Source · SVG

Approche traditionnelle	Approche Sigstore
Clé privée à protéger pendant des années	Clé détruite après quelques minutes
Rotation complexe et manuelle	Pas de rotation (certificat éphémère)
Révocation problématique	Pas de révocation à organiser
Distribution des clés publiques	Identité vérifiée par OIDC
Confiance basée sur la clé	Confiance basée sur l'identité et un journal public

Le prix à payer est une connexion Internet au moment de la signature, pour joindre Fulcio, Rekor et l'autorité d'horodatage (timestamp.sigstore.dev). Pour les réseaux fermés, les outils Sigstore acceptent aussi des clés classiques, ou une pile Sigstore déployée en interne.

Quelles sont les briques de Sigstore ?

Sigstore est un projet de l'OpenSSF (Open Source Security Foundation, une fondation de la Linux Foundation). Il se compose de quatre briques qui s'enchaînent : aucune ne suffit seule, c'est leur enchaînement qui produit la garantie finale.

Fulcio est l'autorité de certification : elle vérifie un jeton OIDC et délivre un certificat éphémère lié à l'identité. Elle a sa leçon, Fulcio.
Rekor est le journal de transparence, un registre public en ajout seul où chaque signature reçoit une preuve d'inclusion. Détails dans Rekor.
Cosign signe et vérifie les images de conteneur, les fichiers et les attestations. C'est l'outil que l'on manipule au quotidien, voir Cosign.
gitsign signe les commits Git sans clé GPG, présenté dans gitsign.

Le schéma retrace le trajet complet d'une signature, de l'authentification OIDC jusqu'à l'enregistrement dans Rekor. Suivez les flèches dans l'ordre : chaque brique n'intervient qu'à une étape précise.

Fulcio : autorité de certification qui délivre des certificats éphémères. Cosign : outil de signature qui orchestre le processus. Rekor : log de transparence qui enregistre et prouve. Source · SVG

Comment fonctionne la signature keyless ?

La signature keyless (« sans clé » à long terme) se déroule en cinq étapes. Le mot est trompeur : une clé éphémère existe bien, mais elle ne vit que quelques secondes. Ce qui remplace la gestion de clé, c'est la preuve d'identité fournie par votre fournisseur OIDC.

Authentification OIDC

Vous vous authentifiez auprès d'un fournisseur OIDC (GitHub, Google, Microsoft, GitLab). En CI, c'est la plateforme elle-même qui fournit le jeton d'identité du workflow.
Délivrance du certificat (Fulcio)

Fulcio vérifie le jeton OIDC et génère un certificat X.509 éphémère (X.509 est le format standard des certificats, celui du HTTPS) lié à votre identité (votre email, ou l'identité du workflow CI/CD). Il expire après environ 10 minutes.
Signature de l'artefact (Cosign ou gitsign)

L'outil signe l'artefact avec la clé privée associée au certificat, puis détruit cette clé immédiatement.
Enregistrement (Rekor)

La signature part dans Rekor, qui l'inscrit dans un journal immuable et renvoie un horodatage signé par Rekor (le signed entry timestamp, ou SET). Même si le certificat expire, la signature reste vérifiable grâce à cette preuve temporelle.

Cette preuve n'a pas toujours la même origine. Avec Rekor v1, la version décrite dans cette leçon, c'est le SET, l'horodatage du journal lui-même. Rekor v2 n'horodate plus lui-même : la date vient d'une autorité d'horodatage (TSA, au format RFC 3161), une brique séparée. Cette TSA n'est pas réservée à la v2. En octobre 2026, le signing config public de Sigstore référence timestamp.sigstore.dev, et la documentation Cosign indique que Cosign utilise une TSA « quand c'est approprié », sans option à passer : sur l'instance publique, ne la considérez donc pas comme facultative. Une instance privée la désactive explicitement avec --no-default-tsa.
Vérification

N'importe qui peut contrôler que la signature est valide, qu'elle a été créée pendant la validité du certificat, et qu'elle figure dans Rekor.

Qu'est-ce qu'un journal de transparence ?

Un journal de transparence est un registre public où chaque entrée est liée cryptographiquement aux précédentes grâce à un arbre de Merkle. Cette structure garantit que personne ne peut modifier une entrée passée sans que ce soit détectable, que personne ne peut en supprimer, et que n'importe qui peut vérifier qu'une entrée existe.

Le principe n'est pas nouveau. Certificate Transparency enregistre déjà tous les certificats TLS émis pour détecter les certificats frauduleux, et Sigstore applique la même idée à la signature de code. Le tableau montre ce que le journal apporte par rapport à une signature seule.

Sans journal de transparence	Avec Rekor
Impossible de prouver quand une signature a été créée	Horodatage cryptographique
Si quelqu'un signe en votre nom, comment le savoir ?	Toutes vos signatures sont auditables
La révocation d'une clé est complexe	Les signatures passées restent valides
Confiance aveugle dans le signataire	Traçabilité publique

Le fonctionnement détaillé des arbres de Merkle et des preuves d'inclusion est dans la leçon Rekor.

Faut-il utiliser l'instance publique ou une instance privée ?

Sigstore propose des instances publiques gratuites, pratiques pour l'écosystème open source, et peut aussi se déployer en privé. Les adresses publiques sont fulcio.sigstore.dev pour les certificats et rekor.sigstore.dev pour le journal, avec l'interface web search.sigstore.dev pour explorer les entrées.

Le point d'attention est la vie privée : les signatures du Rekor public sont visibles par tous, et l'email de votre identité OIDC y apparaît. Si l'anonymat ou la confidentialité comptent, ou si l'environnement est coupé d'Internet, on déploie sa propre pile (voir les leçons Fulcio et Rekor pour le déploiement privé) ou on retombe sur des clés classiques.

Quel outil Sigstore pour quel artefact ?

Sigstore est une famille d'outils, et le bon choix dépend de ce que vous signez. Retenez que Cosign couvre à lui seul la majorité des cas (images, fichiers, SBOM, attestations) et que gitsign est le seul outil spécifique, réservé aux commits Git.

Ce que vous signez	Outil à utiliser
Une image de conteneur	Cosign
Un commit Git	gitsign
Un binaire ou une archive	Cosign (signature de fichier, dite « blob »)
Un SBOM ou une attestation	Cosign avec `cosign attest`
Une politique de chaîne d'approvisionnement	in-toto avec Cosign

La dernière ligne renvoie à in-toto, le cadre qui décrit les attestations que Cosign signe ensuite.

Comment signer en CI/CD avec GitHub Actions ?

En CI, il n'y a personne pour cliquer sur « se connecter » : c'est la plateforme qui fournit le jeton OIDC du workflow, et Fulcio y lit l'identité du dépôt et du workflow. Il suffit d'accorder la permission id-token: write au job, sans stocker aucun secret de signature.

name: Build and Sign

on:
  push:
    tags: ['v*']

# Permissions minimales au top-level
permissions:
  contents: read

jobs:
  build-sign:
    runs-on: ubuntu-24.04

    # Permissions spécifiques au job
    permissions:
      contents: read
      packages: write       # Pour push vers GHCR
      id-token: write       # Pour OIDC Sigstore
      attestations: write   # Pour GitHub Attestations

    steps:
      - name: Checkout code
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c # v4.2.0

      - name: Install Cosign
        uses: sigstore/cosign-installer@6f9f17788090df1f26f669e9d70d6ae9567deba6 # v4.1.2

      - name: Log in to GHCR
        uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push
        id: build
        uses: docker/build-push-action@53b7df96c91f9c12dcc8a07bcb9ccacbed38856a # v7.3.0
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}
          provenance: true  # Génère l'attestation SLSA
          sbom: true        # Génère le SBOM avec Syft

      - name: Generate SLSA attestation
        uses: actions/attest-build-provenance@0f67c3f4856b2e3261c31976d6725780e5e4c373 # v4.1.1
        with:
          subject-name: ghcr.io/${{ github.repository }}
          subject-digest: ${{ steps.build.outputs.digest }}
          push-to-registry: true

      - name: Sign image
        env:
          # Passer par l'environnement évite l'injection de template dans le script
          REPO: ${{ github.repository }}
          DIGEST: ${{ steps.build.outputs.digest }}
        run: |
          IMAGE="ghcr.io/${REPO}@${DIGEST}"
          cosign sign --yes "${IMAGE}"

          # Vérification immédiate
          cosign verify \
            --certificate-identity-regexp="^https://github.com/${REPO}/" \
            --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
            "${IMAGE}"

Lisez ce workflow en quatre points. Les permissions sont minimales au niveau du workflow, puis élargies seulement pour le job de signature. Les actions sont épinglées sur le SHA du commit. L'étape Log in to GHCR authentifie le job auprès du registre avec le GITHUB_TOKEN : sans elle, ni l'image ni sa signature ne peuvent être poussées. La signature se fait sur le digest de l'image, pas sur un tag mutable, et elle est vérifiée aussitôt avec l'identité attendue du workflow et l'émetteur OIDC de GitHub, ce qui révèle un problème dès la signature plutôt qu'au déploiement.

GitHub Actions n'est pas la seule plateforme à fournir un jeton OIDC exploitable : GitLab CI, Google Cloud Build et CircleCI le font aussi. La mise en oeuvre pas à pas est dans la leçon Cosign, et la signature de commits dans gitsign.

Quel lien entre Sigstore et SLSA ?

SLSA (Supply chain Levels for Software Artifacts) définit des niveaux de maturité pour la sécurité de la chaîne de build. Sigstore fournit les briques de signature qui permettent d'atteindre ces niveaux, comme le résume le tableau.

Niveau SLSA	Exigence	Apport de Sigstore
Build L1	Provenance existe	Cosign (signature)
Build L2	Provenance signée	Cosign + Fulcio
Build L3	Build isolé, provenance non forgeable	Cosign + attestations in-toto

Attention à ne pas confondre l'outil et le niveau : selon la documentation de GitHub, les artifact attestations seules, produites par actions/attest-build-provenance, donnent le niveau SLSA Build L2. Le niveau L3 exige en plus un build isolé de ce qu'exécute l'appelant, par exemple dans un workflow réutilisable que le dépôt n'est pas libre de modifier.

Pour des attestations avancées, combinez Sigstore avec in-toto. Le choix de niveau et la lecture d'une provenance sont traités dans la leçon SLSA : décider du niveau.

Qui utilise Sigstore aujourd'hui ?

L'adoption par de grands écosystèmes est un bon indicateur de maturité d'un outil de sécurité. npm signe les provenances de ses paquets avec Sigstore, PyPI propose les Trusted Publishers (publication par identité OIDC) et des attestations de publication, Kubernetes signe ses releases, GitHub émet des attestations de provenance, et Wolfi/Chainguard signe ses images. Quand les registres de paquets signent à cette échelle, la vérification côté consommateur devient une pratique réaliste.

Le journal public Rekor compte des milliards d'entrées (environ 3,2 milliards d'après l'API /api/v1/log le 16 octobre 2026), un volume qui croît chaque jour. Le chiffre exact varie vite et se lit via cette API ou sur l'interface search.sigstore.dev.

Que garantit une signature Sigstore ?

Une signature apporte quatre garanties précises. Les deux premières (authenticité et intégrité) répondent à « qui a produit ce fichier, et a-t-il été altéré ? ». Les deux suivantes (non-répudiation et horodatage) viennent du journal Rekor, complété par une autorité d'horodatage (TSA) pour la date, et répondent à « peut-on le prouver publiquement, et depuis quand ? ».

Garantie	Explication
Authenticité	L'artefact a été signé par l'identité déclarée
Intégrité	L'artefact n'a pas été modifié depuis la signature
Non-répudiation	La signature est enregistrée publiquement : le signataire ne peut pas nier l'avoir faite
Horodatage	On sait quand la signature a été créée

Le schéma isole la part qui revient au journal Rekor : ce qu'il garantit, à gauche, et ce qu'il ne garantit pas, à droite.

En résumé : Rekor prouve qui a signé quoi et quand, mais pas si c'était une bonne idée de signer. Source · SVG

Que ne garantit-elle pas ?

C'est la section la plus importante, car une signature crée une confiance qui peut être mal placée. Une signature valide prouve qui a produit l'artefact et qu'il n'a pas bougé depuis, rien de plus. Un paquet malveillant correctement signé reste malveillant : la signature dit à qui demander des comptes, pas si le contenu est sûr.

Non-garantie	Explication
Qualité du code	Un artefact signé peut contenir des bugs ou des failles
Intentions	Le signataire peut être malveillant
Sécurité du build	Sigstore ne protège pas le pipeline de build

Ces limites expliquent pourquoi la signature ne vient jamais seule : elle se combine avec un inventaire (SBOM), une provenance de build et des politiques de vérification au déploiement.

À retenir

Keyless, pas sans clé : une clé existe quelques secondes, ce qui remplace sa gestion est l'identité OIDC et un certificat éphémère.
Quatre briques : Fulcio délivre le certificat, Cosign et gitsign signent, Rekor journalise et horodate.
Le journal rend la signature vérifiable après l'expiration du certificat grâce à la preuve d'inclusion.
En CI, la plateforme fournit le jeton OIDC (id-token: write) : aucun secret de signature à stocker, et on signe le digest, pas le tag.
La signature prouve qui et quand, pas que le code est sûr : elle se combine avec SBOM, provenance et politique de vérification.
Preuve attendue : une signature vérifiée avec l'identité et l'émetteur OIDC attendus, et l'entrée correspondante dans Rekor.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

Sigstore : signature keyless pour la supply chain

Ce que vous allez apprendre

Pourquoi signer sans clé longue durée ?

Quelles sont les briques de Sigstore ?

Comment fonctionne la signature keyless ?

Qu'est-ce qu'un journal de transparence ?

Faut-il utiliser l'instance publique ou une instance privée ?

Quel outil Sigstore pour quel artefact ?

Comment signer en CI/CD avec GitHub Actions ?

Quel lien entre Sigstore et SLSA ?

Qui utilise Sigstore aujourd'hui ?

Que garantit une signature Sigstore ?

Que ne garantit-elle pas ?

À retenir

Contrôle de connaissances

Contrôle de connaissances

Informations

Vérification

Score par domaine

Bilan

Points forts

Points faibles

À faire ensuite