Sigstore est un projet CNCF qui permet de signer des artefacts logiciels (containers, binaires, SBOM) sans gérer de clés cryptographiques persistantes. La signature est faite à partir d'une identité OIDC (GitHub, Google, Microsoft Entra) au moment du build, puis stockée dans un transparency log public (Rekor) pour vérification ultérieure. Adopté par Kubernetes, Python (PyPI), npm, Linux Foundation, c'est le standard de fait en 2024-2026.
Voici comment démarrer en 30 minutes sur un pipeline GitHub Actions, et l'étendre proprement.
Pourquoi Sigstore plutôt que GPG ou clés statiques
Les approches traditionnelles de signature exigent :
- Génération de clés privées long-terme.
- Stockage sécurisé des clés (HSM, vault).
- Distribution des clés publiques aux vérificateurs.
- Gestion de la rotation, expiration, révocation.
Pour un éditeur SaaS qui veut signer ses 50 builds par jour, c'est lourd à opérer. Sigstore résout :
- Pas de clé persistante : la clé éphémère est dérivée de votre identité OIDC au build.
- Transparency log public (Rekor) : toute signature est inscrite, vérifiable par n'importe qui.
- Identité-based : "ce binaire a été construit par GitHub Actions du repo X par le commit Y" est une affirmation cryptographique.
- Adoption massive : les outils existent partout, pas besoin d'inventer.
Setup minimal — pipeline GitHub Actions
Étape 1 : permissions du workflow
Dans .github/workflows/build.yml :
``yaml permissions: id-token: write # nécessaire pour OIDC contents: read packages: write # si push vers GitHub Container Registry ``
Le id-token: write est ce qui permet au runner d'obtenir un token OIDC GitHub utilisable par Sigstore.
Étape 2 : installation de cosign
```yaml
- name: Install cosign
uses: sigstore/cosign-installer@v3 with: cosign-release: 'v2.4.0' ```
Étape 3 : signature de l'image
Pour une image Docker poussée sur GitHub Container Registry :
```yaml
- name: Login GHCR
uses: docker/login-action@v3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }}
- name: Build and push image
id: build uses: docker/build-push-action@v5 with: push: true tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
- name: Sign image with Sigstore
env: COSIGN_EXPERIMENTAL: 1 run: | cosign sign --yes ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }} ```
C'est tout. Au build suivant, votre image sera signée automatiquement, sans aucune clé secrète configurée.
Étape 4 : vérification
N'importe qui (vous, vos clients, un auditeur CRA) peut vérifier :
`` cosign verify ghcr.io/yourorg/yourrepo:v1.2.3 \ --certificate-identity-regexp "https://github.com/yourorg/yourrepo/.+" \ --certificate-oidc-issuer https://token.actions.githubusercontent.com ``
Si la vérification passe, c'est que :
- L'image a été signée par GitHub Actions du repo spécifié.
- La signature est inscrite dans Rekor (transparency log).
- L'image n'a pas été modifiée depuis la signature.
Au-delà des images : tout signer
Sigstore n'est pas limité aux containers Docker. Vous pouvez signer :
Binaires et artefacts
``` # Signer cosign sign-blob --yes --bundle artifact.bundle myapp.tar.gz
# Vérifier cosign verify-blob --bundle artifact.bundle \ --certificate-identity-regexp "https://github.com/yourorg/.+" \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ myapp.tar.gz ```
SBOM
`` # Attacher un SBOM signé à une image cosign attach sbom --sbom sbom.cdx.json \ ghcr.io/yourorg/yourrepo:v1.2.3 cosign sign --yes \ --attachment sbom \ ghcr.io/yourorg/yourrepo:v1.2.3 ``
Attestations SLSA
SLSA (Supply chain Levels for Software Artifacts) utilise Sigstore pour attester la provenance reproductible. À partir du Level 2.
Vérification en production : enforcement
Pour ne déployer que des images signées, utilisez :
- Kyverno (Kubernetes admission controller) avec policy Cosign keyless.
- Sigstore Policy Controller (CNCF officiel).
- OPA/Gatekeeper avec custom rule.
Exemple Kyverno :
``yaml apiVersion: kyverno.io/v2beta1 kind: ClusterPolicy metadata: name: verify-image-sigstore spec: validationFailureAction: Enforce rules: - name: verify-cosign match: any: - resources: kinds: [Pod] verifyImages: - imageReferences: ["ghcr.io/yourorg/"] attestors: - entries: - keyless: subject: "https://github.com/yourorg/" issuer: "https://token.actions.githubusercontent.com" ``
Avec cette policy active, votre cluster Kubernetes refuse tout pod qui n'utilise pas une image signée par votre pipeline GitHub. Pratique pour bloquer les images sauvages introduites par accident ou malice.
Coût et performance
- Coût : zéro. Sigstore est gratuit, opéré par Linux Foundation. Pas de frais d'usage.
- Latence build : +5 à 15 secondes par image signée (négligeable).
- Stockage : le bundle de signature est de quelques KB, négligeable.
Pas de raison de ne pas le mettre en place.
Sigstore et CRA
Le Cyber Resilience Act (application complète décembre 2027) demande pour les "important" et "critical" produits :
- Signature des artefacts livrés.
- Provenance documentée et vérifiable.
- SBOM signé et lié à l'artefact.
Sigstore est précisément ce qu'il faut. Voir CRA roadmap des jalons 2026-2027 pour le contexte complet.
Le piège : signer sans vérifier
Une signature Sigstore qui n'est jamais vérifiée par personne est cosmétique. Pour que l'investissement ait du sens :
- Pipeline de déploiement vérifie la signature avant déploiement (admission controller).
- Documentation publique indique aux clients comment vérifier vos artefacts.
- Acheteurs DDQ : vous mentionnez Sigstore dans vos questionnaires sécurité.
Sans ce trio, vous payez pour une signature symbolique. Avec, vous avez une vraie chaîne de provenance auditable.
