Schéma du workflow Sigstore : signature automatique par GitHub/GitLab, journal public Rekor, vérification par l'utilisateur.

Sigstore débarque sur GitHub et GitLab : pourquoi la signature de code devient enfin simple (et indispensable)

Sigstore, le standard open source pour la signature de code, est désormais intégré à GitHub et GitLab. Pourquoi cette avancée change la donne pour la sécurité des logiciels, comment l’utiliser dès aujourd’hui, et quels sont les pièges à éviter ?

Tu télécharges un logiciel open source, tu l’installes, et tu te demandes : « Qui l’a vraiment écrit ? Est-ce que quelqu’un a modifié le code avant moi ? » Jusqu’ici, répondre à ces questions demandait des compétences en cryptographie et une bonne dose de patience. Mais en août 2026, GitHub et GitLab ont intégré Sigstore, un standard open source qui rend la signature de code aussi simple qu’un commit. Pour les développeurs, c’est une révolution : plus besoin de gérer des clés PGP ou de se battre avec des outils complexes. Pour les utilisateurs, c’est une garantie : le logiciel que tu utilises est bien celui que le mainteneur a publié, sans modification malveillante.

Sigstore, c’est quoi ?

Sigstore est un standard open source pour signer et vérifier du code, des artefacts, et des containers. Créé par la Linux Foundation, Google, Red Hat, et d’autres, il élimine les barrières techniques qui empêchaient la plupart des développeurs de signer leur code. Au lieu de gérer des clés PGP complexes, Sigstore utilise :

  • Des certificats courts (via Fulcio), valables quelques minutes seulement, pour limiter les risques de fuite.
  • Une identité OpenID Connect (GitHub, GitLab, Google, Microsoft…), pour prouver qui tu es sans gérer de clés.
  • Un journal public (Rekor), qui enregistre toutes les signatures et permet à quiconque de vérifier qui a signé quoi, et quand.

Pourquoi c’est important ?

Les attaques par supply chain (comme SolarWinds ou xz) exploitent des failles dans la distribution du code. Un attaquant modifie un logiciel en transit, et des milliers d’utilisateurs installent une version piégée sans le savoir. Sigstore rend ces attaques beaucoup plus difficiles :

  • Sécurité : si le code est signé, toute modification invalide la signature. Impossible d’injecter du code malveillant sans que ça se voie.
  • Transparence : tout le monde peut vérifier qui a signé un logiciel, et quand. Plus de doute sur l’origine du code.
  • Simplicité : plus besoin de gérer des clés PGP ou de configurer des outils complexes. GitHub et GitLab s’occupent de tout.
Schéma du workflow Sigstore : signature automatique par GitHub/GitLab, journal public Rekor, vérification par l'utilisateur.

Schéma : workflow Sigstore — signature automatique, journal public, vérification par l’utilisateur.

Comment ça marche sur GitHub et GitLab ?

En août 2026, GitHub et GitLab ont intégré Sigstore nativement. Voici comment ça fonctionne :

  • GitHub : lors d’un push ou d’un release, GitHub signe automatiquement les artefacts avec Sigstore (via Cosign). Les utilisateurs peuvent vérifier la signature avec une simple commande :
cosign verify --key https://github.com/<user>/<repo>.pem <binaire>
  • GitLab : même principe, avec une intégration native dans les pipelines CI/CD. Les artefacts sont signés automatiquement, et les utilisateurs peuvent vérifier la signature de la même manière.
  • Exemple concret : tu télécharges un binaire depuis GitHub Releases. Avec Sigstore, tu peux vérifier que ce binaire a bien été signé par le mainteneur du projet, et qu’il n’a pas été modifié depuis. Si la signature est invalide, c’est un signal d’alerte : le binaire a peut-être été compromis.

Comment l’utiliser dès aujourd’hui ?

Pour les développeurs :

  • Active Sigstore dans les paramètres de ton dépôt GitHub ou GitLab.
  • Utilise cosign sign pour signer tes artefacts manuellement, ou laisse GitHub/GitLab le faire automatiquement.
  • Vérifie les signatures avec cosign verify.

Pour les utilisateurs :

  • Vérifie la signature d’un logiciel avant de l’installer. Exemple :
cosign verify --key https://github.com/<user>/<repo>.pem <binaire>
  • Utilise des outils comme sigstore-python pour automatiser la vérification.
Logo de Sigstore, un standard open source pour la signature et la vérification de code.

Source : logo Sigstore — sigstore.dev (licence Apache 2.0)

Les pièges à éviter

  • Ne pas signer = ne pas être protégé : Sigstore ne protège que les artefacts signés. Si un projet ne l’utilise pas, tu restes vulnérable aux attaques par supply chain.
  • Vérifier la chaîne de confiance : une signature valide ne garantit pas que le code est sûr, seulement qu’il vient bien de la personne qui l’a signé. Un mainteneur malveillant peut signer du code dangereux.
  • Ne pas se fier uniquement à GitHub/GitLab : Sigstore est open source, tu peux l’utiliser en dehors de ces plateformes (exemple : signer tes artefacts sur ton propre serveur).

Conclusion : une avancée majeure pour la sécurité open source

Sigstore intégré à GitHub et GitLab, c’est une étape clé pour la sécurité des logiciels open source. En rendant la signature de code accessible à tous, cette intégration réduit les risques d’attaques par supply chain et renforce la confiance dans les logiciels que nous utilisons au quotidien. Pour les développeurs, c’est l’occasion de sécuriser leurs projets en quelques clics. Pour les utilisateurs, c’est une raison de plus de privilégier les logiciels open source — à condition de vérifier les signatures !

Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.

No comments yet