Sigstore : signature keyless pour la supply chain

Signer des artefacts logiciels, c'est bien. Mais gérer des clés cryptographiques sur le long terme ? C'est un cauchemar opérationnel : rotation, stockage sécurisé, révocation, distribution des clés publiques...

Sigstore résout ce problème fondamental avec la signature keyless : vous signez avec votre identité (OIDC), pas avec une clé que vous devez protéger. Chaque signature est enregistrée dans un log de transparence public qui garantit l'auditabilité et la non-répudiation.

Cette signature et cette traçabilité matérialisent les exigences de provenance et d'intégrité des livrables du référentiel Socle DevSecOps.

Pourquoi Sigstore change la donne

Le problème de la gestion des clés

Avant Sigstore, signer un artefact nécessitait de :

1. Générer une paire de clés (RSA, ECDSA...)
2. Protéger la clé privée (HSM, KMS, Vault...)
3. Distribuer la clé publique (comment vos utilisateurs la récupèrent-ils ?)
4. Gérer la rotation (tous les ans ? tous les 2 ans ?)
5. Gérer la révocation (que faire si la clé est compromise ?)
6. Maintenir la confiance (comment prouver que la clé appartient bien à vous ?)

Chaque étape est une source potentielle d'erreur ou de compromission.

La solution Sigstore

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

Glissez pour voir

Compromis à connaître

La signature keyless nécessite une connexion Internet au moment de la signature (pour contacter Fulcio et Rekor). Pour des environnements air-gapped, les outils Sigstore supportent aussi les clés traditionnelles.

L'architecture Sigstore

Sigstore est un projet de l'OpenSSF (Open Source Security Foundation, Linux Foundation) composé de quatre briques complémentaires qui fonctionnent ensemble.

Vue d'ensemble

Le schéma ci-dessous retrace le trajet complet d'une signature, de l'authentification OIDC jusqu'à l'enregistrement dans Rekor. Suivez les flèches dans l'ordre : chacune des quatre briques n'intervient qu'à une étape précise, et c'est leur enchaînement, et non un composant isolé, qui produit la garantie finale. Gardez ce flux en tête, les sections suivantes détaillent chaque étape une par une.

Les quatre composants

Fulcio Autorité de certification OIDC qui vérifie votre identité et délivre un certificat éphémère

Rekor Log de transparence immuable, le registre public des signatures

Cosign Signature d'images conteneur et attestations SBOM

gitsign Signature de commits Git sans clés GPG

Comment fonctionne la signature keyless

1. Authentification OIDC

   Vous vous authentifiez via un provider OIDC (GitHub, Google, Microsoft, GitLab...). C'est la même authentification que vous utilisez pour vous connecter à ces services.

2. Délivrance du certificat (Fulcio)

   Fulcio vérifie votre token OIDC et génère un certificat X.509 éphémère lié à votre identité. Ce certificat contient votre email (ou l'identité du workflow CI/CD) et expire après 10 minutes.

3. Signature de l'artefact (Cosign/gitsign)

   L'outil de signature utilise la clé privée associée au certificat pour signer votre artefact. La clé privée est immédiatement détruite après usage.

4. Enregistrement (Rekor)

   La signature est envoyée à Rekor qui l'enregistre dans un log immuable avec un timestamp RFC3161. Même si le certificat expire, la signature reste vérifiable grâce à cette preuve temporelle.

5. Vérification

   N'importe qui peut vérifier que la signature est valide, qu'elle a été créée pendant la période de validité du certificat, et qu'elle est enregistrée dans Rekor (non-répudiation).

Les logs de transparence

Le concept clé

Un log de transparence est un registre public où chaque entrée est cryptographiquement liée aux précédentes (arbre de Merkle). Cette structure garantit que :

• Personne ne peut modifier une entrée passée sans que ce soit détectable
• Personne ne peut supprimer une entrée
• N'importe qui peut vérifier qu'une entrée existe dans le log

Certificate Transparency : l'inspiration

Si vous utilisez HTTPS, vous bénéficiez déjà des logs de transparence ! Certificate Transparency (CT) enregistre tous les certificats TLS émis, permettant de détecter les certificats frauduleux. Sigstore applique ce concept à la signature de code.

Pourquoi c'est révolutionnaire

Sans log de transparence	Avec Rekor
Impossible de prouver quand une signature a été créée	Timestamp 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

Glissez pour voir

Pour comprendre en détail le fonctionnement des arbres de Merkle et des preuves d'inclusion, consultez le guide Rekor.

Instances publiques vs privées

Sigstore propose des instances publiques gratuites pour l'écosystème open source, mais peut aussi être déployé en privé.

Instances publiques

Service	URL	SLA	Usage
Fulcio	fulcio.sigstore.dev	99.5%	Certificats OIDC
Rekor	rekor.sigstore.dev	99.5%	Log de transparence
Rekor Search	search.sigstore.dev	-	Interface web

Glissez pour voir

Vie privée

Les signatures dans Rekor public sont visibles par tous. L'email associé à votre identité OIDC est public. Si l'anonymat est important, utilisez une instance privée ou des clés traditionnelles.

Déploiement privé

Pour les environnements qui nécessitent confidentialité, air-gapped ou contrôle total, vous pouvez déployer votre propre stack Sigstore. Consultez le guide de déploiement privé Rekor.

Quel outil utiliser ?

Sigstore n'est pas un outil unique mais une famille, et le bon choix dépend de ce que vous signez. L'arbre de décision ci-dessous part de la nature de l'artefact pour vous renvoyer vers le bon binaire. Retenez que Cosign couvre à lui seul la majorité des cas (images, blobs, SBOM, attestations) ; gitsign est le seul spécifique, réservé à la signature de commits Git.

Que voulez-vous signer ?
│
├─► Images conteneur ──────────────► Cosign
│
├─► Commits Git ───────────────────► gitsign
│
├─► Fichiers binaires / archives ──► Cosign (blob signing)
│
├─► SBOM / attestations ───────────► Cosign attest
│
└─► Politiques supply chain ───────► in-toto + Cosign

Intégration CI/CD

GitHub Actions

GitHub Actions fournit nativement des tokens OIDC compatibles Sigstore :

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: 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}"

Pour plus de détails sur les attestations SBOM et l'intégration Kubernetes, consultez le guide Cosign.

Autres plateformes

GitHub Actions n'est pas la seule plateforme à fournir des tokens OIDC exploitables par Sigstore. Le tableau ci-dessous liste les intégrations natives : la colonne Support OIDC est celle qui compte, car c'est ce jeton d'identité fourni par la plateforme qui rend la signature keyless possible, sans clé à stocker dans les secrets du pipeline.

Plateforme	Support OIDC	Documentation
GitHub Actions	✅ Natif	guide Cosign
GitLab CI	✅ Natif	guide gitsign
Google Cloud Build	✅ Natif	docs.sigstore.dev
CircleCI	✅ Disponible	circleci.com

Glissez pour voir

Sigstore et SLSA

SLSA (Supply chain Levels for Software Artifacts) définit des niveaux de maturité pour la sécurité supply chain. Sigstore est l'outil de référence pour atteindre ces niveaux :

Niveau SLSA	Exigence	Outil 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

Glissez pour voir

Pour des attestations avancées, combinez Sigstore avec in-toto.

Adoption dans l'industrie

Qui utilise Sigstore ?

L'adoption par des écosystèmes majeurs est le meilleur indicateur de maturité d'un outil de sécurité. La liste ci-dessous regroupe des registres de paquets (npm, PyPI, Homebrew) et des projets d'infrastructure (Kubernetes, Chainguard) qui ont intégré Sigstore dans leur chaîne de publication. Ce n'est pas anecdotique : quand npm signe des millions de paquets par semaine, la vérification côté consommateur devient une pratique réaliste, pas un cas théorique.

• npm : 2M+ signatures/semaine depuis 2023
• PyPI : Trusted Publishers (OIDC natif)
• Kubernetes : toutes les releases signées
• GitHub : attestations de provenance
• Homebrew : signatures des formules
• Wolfi/Chainguard : toutes les images signées

Statistiques Rekor (2025)

Le log public contient plus de 100 millions d'entrées, avec une croissance de ~500K signatures/jour.

Sécurité et limites

Bonnes pratiques de sécurité

Permissions minimales

Définissez permissions: au niveau workflow avec contents: read par défaut, puis accordez des permissions spécifiques au niveau job.

Actions pinnées par SHA

Utilisez toujours des SHA de commit pour les actions tierces : uses: actions/checkout@8e8c483... # v6.0.1

Vérification post-signature

Toujours vérifier la signature immédiatement après l'avoir créée pour détecter les problèmes tôt.

Attestations SLSA

Utilisez actions/attest-build-provenance pour atteindre SLSA Build L3 et faciliter la vérification avec gh attestation verify.

Ce que Sigstore garantit

Signer un artefact apporte quatre garanties précises, qu'il faut savoir nommer pour ne pas en attendre davantage. Les deux premières (authenticité et intégrité) répondent à « qui a produit ce fichier et n'a-t-il pas été altéré ». Les deux suivantes (non-répudiation et horodatage) viennent du log Rekor et répondent à « peut-on le prouver publiquement, et depuis quand ». Ce sont ces garanties, et elles seules, que la section suivante viendra délimiter par la négative.

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
Horodatage	On sait quand la signature a été créée

Glissez pour voir

Ce que Sigstore ne garantit PAS

C'est la section la plus importante de la page, car la 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. Elle ne dit rien de la qualité du code, ni des intentions du signataire, ni de la sécurité du pipeline qui a fabriqué l'artefact. Un paquet malveillant correctement signé reste malveillant : la signature vous 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 failles
Intentions	Le signataire peut être malveillant
Sécurité du build	Sigstore ne protège pas le pipeline de build

Glissez pour voir

À retenir

1. Keyless = pas de clé à gérer : certificat éphémère basé sur OIDC
2. Quatre composants : Fulcio (identité) + Rekor (transparence) + Cosign + gitsign
3. Log de transparence : toutes les signatures sont publiques et auditables
4. Adoption massive : npm, PyPI, Kubernetes, GitHub utilisent Sigstore
5. SLSA-ready : atteint Build L2 nativement, L3 avec attestations

Guides détaillés

Cosign Signer images conteneur, attestations SBOM, intégration Kubernetes

Rekor Requêtes CLI, vérification, déploiement privé

Fulcio Autorité de certification OIDC, providers supportés

gitsign Signer vos commits Git sans clés GPG

in-toto Framework d'attestations pour SLSA L3

Ressources externes

• Documentation officielle Sigstore
• Rekor Search, Explorer le log public
• Sigstore sur GitHub
• Blog Sigstore
• OpenSSF, Fondation mère du projet

×

📖 Voir la documentation →