Preuve d'existence et Sigstore : avez-vous besoin des deux ?

Sigstore et la preuve d'existence ne sont pas vraiment concurrents. Sigstore répond à la question : qui a signé cet artefact logiciel, et l'événement de signature figure-t-il dans un journal public ? Label 309 répond à une autre question : ces octets exacts existaient-ils avant une date publique, de manière prouvable sans avoir à faire confiance à un service unique ? Pour la plupart des équipes logicielles, la configuration la plus solide combine les deux : signer et journaliser les versions avec Sigstore, puis ancrer les pièces de version avec Label 309.

Sigstore est un écosystème de signature logicielle et de transparence. Label 309 ancre des empreintes de contenu, des manifestes, des fichiers scellés ou une racine de Merkle sur Cardano, de sorte que n'importe qui puisse vérifier plus tard que ces données exactes existaient avant un temps de bloc précis — en s'appuyant uniquement sur la transaction et un explorateur public, sans aucun serveur de l'émetteur dans la boucle.

Qu'est-ce que Sigstore ?

Sigstore est un écosystème open source qui sert à signer les artefacts de la chaîne d'approvisionnement logicielle et à enregistrer les événements de signature dans un journal public.

Son flux sans clé courant repose sur une identité OpenID Connect (OIDC), un certificat à courte durée de vie émis par Fulcio, une signature créée côté client et une entrée dans le journal de transparence Rekor. L'objectif est de faciliter la signature des artefacts tout en conservant un registre public et auditable de qui a signé quoi.

Sigstore convient particulièrement à :

les images de conteneurs ;
les binaires et les paquets ;
les nomenclatures logicielles (SBOM) ;
les attestations de provenance ;
les flux CI/CD et de signature de version ;
la vérification qu'un artefact a bien été signé par l'identité attendue.

Il est conçu pour instaurer la confiance dans la chaîne d'approvisionnement logicielle.

Qu'est-ce que Label 309 ?

Label 309 est un standard ouvert et indépendant des fournisseurs pour les records de preuve d'existence sur Cardano. La proposition a été soumise au processus CIP de Cardano et est en cours d'examen par les éditeurs CIP ; l'identifiant sur la chaîne est le label de métadonnées 309.

Un record Label 309 peut s'engager sur une ou plusieurs empreintes de contenu, une racine de Merkle couvrant de nombreux fichiers, des signatures facultatives au niveau du record, des contenus scellés adressés à des clés de destinataires et des URI de stockage adressé par le contenu. La preuve fondamentale est vérifiable de manière indépendante à partir de la transaction Cardano et des octets contrôlés — sans compte, sans connexion et sans dépendre d'un fournisseur unique.

Pour les équipes logicielles, cela le rend utile pour ancrer les pièces de version :

les condensés d'artefacts ;
les bundles Sigstore ;
les provenances SLSA et les déclarations in-toto ;
les SBOM ;
les manifestes de version ;
les journaux de build et les résultats de tests ;
les pièces relatives aux incidents.

C'est une couche d'engagement publique et horodatée.

Quelle est la différence réelle ?

Sigstore répond aux questions d'identité et de signature pour les logiciels. Label 309 répond aux questions d'existence et de temporalité pour n'importe quels octets.

Sigstore peut aider à répondre à :

Cette image de conteneur a-t-elle été signée ?
Quelle identité OIDC était liée au certificat de signature ?
L'événement de signature a-t-il été enregistré dans le journal de transparence ?
La signature de l'artefact peut-elle être vérifiée ?
Cela correspond-il à ma politique de signataires de confiance ?

Label 309 peut aider à répondre à :

Ce condensé d'artefact existait-il avant ce temps de bloc Cardano ?
Cette SBOM faisait-elle partie des pièces de version engagées ?
Ce manifeste de version existait-il avant un incident ?
Une identité de projet connue a-t-elle signé le record (facultativement) ?
Un destinataire pourra-t-il déchiffrer plus tard un bundle de pièces scellé ?

Ces deux ensembles de questions s'articulent plutôt qu'ils ne se recoupent.

Rekor ne le fait-il pas déjà ?

Si vous utilisez Sigstore, utilisez Rekor — c'est l'outil adapté à sa tâche.

Rekor est un journal de transparence pour les signatures et les métadonnées logicielles, conçu pour rendre les événements de signature repérables et auditables. La documentation de Sigstore le décrit comme un registre en ajout-seul, résistant à l'altération, que les auditeurs peuvent surveiller pour en contrôler la cohérence — l'objectif de conception étant que toute tentative de modification ou de suppression d'une entrée soit détectable plutôt que silencieuse.

Label 309 ne remplace pas Rekor. Il fournit un type d'ancrage différent :

un horodatage public enraciné dans le consensus Cardano, et non dans un journal exploité par un service ;
un schéma de record défini sous le label de métadonnées 309 ;
une préservation scellée facultative des pièces sensibles ;
une remise à des destinataires précis ;
un regroupement Merkle pour les grands ensembles de pièces ;
une vérification qui ne dépend du maintien en ligne d'aucun fournisseur particulier.

Si une version dispose déjà de pièces Sigstore, ancrez-les. Ne les jetez pas.

À quoi ressemblerait un flux combiné ?

Un pipeline CI/CD peut assembler un dossier de pièces de version, puis s'y engager.

Ce dossier peut contenir le manifeste de version, les condensés d'artefacts, les signatures ou bundles Cosign, les références d'entrées Rekor, les provenances SLSA, les attestations in-toto, les SBOM, les journaux de build, les rapports de tests et les manifestes de déploiement.

Le pipeline hache chaque fichier, construit un arbre de Merkle et publie un seul record Label 309 portant la racine de Merkle. Comme la racine tient en une seule valeur de 32 octets, une transaction peut représenter un ensemble de pièces de taille arbitraire ; une preuve d'inclusion montre ensuite qu'un fichier précis faisait bien partie de cette racine. Le record peut aussi porter une signature facultative issue d'une identité de projet ou d'entreprise. Pour comprendre le mécanisme qui replie de nombreux fichiers dans une seule racine, voir un seul record pour des milliers de fichiers ; pour le schéma de pipeline de bout en bout, voir ancrer les pièces de build CI/CD.

Plus tard, un auditeur vérifie deux choses indépendantes :

Sigstore — qui a signé quoi, sous quelle identité et dans quel contexte de journal de transparence ;
Label 309 — quel ensemble de pièces existait à une date publique sur Cardano.

Label 309 vérifie-t-il la signature du logiciel ?

Non. Label 309 ne sait pas si une signature Cosign est valide, si une identité OIDC est de confiance, si une politique est satisfaite ou si un build répond aux attentes SLSA.

Ce qu'il peut prouver, c'est que le fichier de signature, le bundle, l'attestation, la SBOM ou le manifeste de version existait à une date publique. Les outils de la chaîne d'approvisionnement logicielle continuent de vérifier leurs propres formats selon leurs propres règles.

Cette séparation est saine. Une preuve d'existence ne doit pas prétendre être un moteur de politique de signature logicielle.

Sigstore préserve-t-il l'ensemble de vos pièces ?

Pas à lui seul. Sigstore se concentre sur la signature et la transparence des artefacts logiciels. Un véritable processus de version doit souvent aussi préserver des journaux de build, des SBOM, des rapports de tests, des manifestes de déploiement, des chronologies d'incidents et des bundles de pièces privés.

Label 309 peut engager ces éléments comme un seul ensemble. Si certains éléments sont sensibles, ils peuvent rester privés et être engagés via une racine de Merkle sans publier leur contenu — ou être scellés, de sorte que le texte chiffré réside dans un stockage adressé par le contenu et que seul un détenteur de clé puisse le déchiffrer. Un record scellé maintient le texte en clair lisible uniquement par les destinataires prévus ; il ne garantit pas à lui seul l'anonymat, et un destinataire peut toujours divulguer le texte en clair après l'avoir déchiffré.

Cela rend Label 309 utile pour l'audit, la réponse aux incidents, les achats, les revues de sécurité des clients et les pièces de version à long terme.

Quand devriez-vous utiliser Sigstore ?

Utilisez Sigstore lorsque vous avez besoin de signer des artefacts logiciels et d'une vérification adossée à une identité. Il est adapté à la signature des images de conteneurs, des binaires et des paquets ; aux flux de version open source publics ; à la signature sans clé avec des identités OIDC ; à la transparence de la chaîne d'approvisionnement ; aux politiques de vérification fondées sur les signataires attendus ; et à l'intégration avec l'outillage de distribution existant.

Sigstore est un choix par défaut solide pour la signature logicielle moderne.

Quand devriez-vous utiliser Label 309 ?

Utilisez Label 309 lorsque vous avez besoin d'un engagement public et horodaté autour des pièces — ancrer des manifestes de version, prouver qu'une SBOM existait avant la divulgation d'une vulnérabilité, engager une racine de Merkle couvrant un ensemble de pièces de version, préserver des éléments d'incident scellés, prouver un ensemble d'artefacts remis à un client, ou conserver une preuve qui ne dépend pas du maintien en ligne d'un fournisseur CI ou d'un tableau de bord de registre d'artefacts.

Label 309 ne remplace pas la signature. C'est un ancrage temporel et un format d'engagement sur les pièces. La CLI cardanowall open source est conçue exactement pour ce type d'automatisation : indépendante du gateway et reposant d'abord sur des graines brutes, elle s'intègre à un pipeline sans qu'aucun site web n'intervienne. Voir utiliser la CLI en automatisation pour le flux complet.

Que ne prouve aucun des deux systèmes ?

Aucun des deux systèmes ne prouve que le logiciel est sûr.

Un artefact signé peut tout de même contenir une vulnérabilité. Une SBOM horodatée peut être incomplète. Un journal de build peut documenter un pipeline mal configuré. Une version peut être bien documentée et rester dangereuse.

Sigstore et Label 309 aident à prouver l'intégrité, l'identité, la transparence, la temporalité et la continuité des pièces. La sécurité elle-même dépend toujours de la revue du code source, de l'isolation des builds, de la gestion des dépendances, des tests, de la réponse aux vulnérabilités et des contrôles opérationnels. Pour les limites générales de ce qu'une preuve peut ou ne peut pas établir, voir ce qu'une preuve ne prouve pas.

En résumé

Utilisez Sigstore pour signer les logiciels et rendre les événements de signature transparents. Utilisez Label 309 pour ancrer les pièces de version — manifestes, journaux et attestations — à une date publique sur Cardano qu'aucun fournisseur ne peut déplacer discrètement. Ensemble, ils rendent l'histoire du logiciel bien plus facile à vérifier par la suite.

Pour aller plus loin

Ancrer les pièces de build CI/CD — le schéma de pipeline complet pour hacher, regrouper et publier les pièces de build.
Un seul record pour des milliers de fichiers — comment une seule racine de Merkle s'engage sur un ensemble de pièces de taille arbitraire.
Utiliser la CLI en automatisation — piloter la publication et la vérification depuis un pipeline avec la CLI cardanowall.
Ce qu'une preuve ne prouve pas — les limites honnêtes d'une preuve d'existence.
Sigstore et sa documentation — la signature sans clé, les certificats Fulcio et le journal de transparence Rekor.