Comment ancrer les preuves de build CI/CD à un horodatage public ?

Oui — un pipeline CI/CD peut publier la preuve de ce qu'il a produit, et à quel moment. Le principe consiste à hacher les sorties qui comptent (artefacts, SBOM, journaux, manifestes de version), à replier ces empreintes dans une seule racine de Merkle, puis à publier un unique record Label 309 pour le build, la version ou la fenêtre temporelle. Plus tard, quiconque peut prouver qu'un artefact ou un manifeste précis faisait partie de ce lot engagé, et que ce lot existait à une heure de bloc publique donnée, voire avant.

Cela ne remplace pas SLSA, Sigstore, GitHub Artifact Attestations ou in-toto. Cela les complète avec une chose qu'aucun d'eux ne fournit directement : un point d'ancrage temporel public, autonome et indépendant de l'émetteur, qu'aucun fournisseur ne contrôle.

Que doit réellement prouver un pipeline CI/CD ?

Partez des preuves que vous pourriez avoir à produire dans un an.

Une preuve CI/CD peut s'engager sur :

• les artefacts de version ;
• les empreintes (digests) d'images de conteneur ;
• les fichiers SBOM (nomenclature logicielle, software bill of materials) ;
• les attestations de provenance SLSA ;
• les métadonnées de lien in-toto ;
• les journaux de build ;
• les rapports de test ;
• les manifestes de déploiement ;
• les instantanés de changelog ;
• les références de commit source ;
• les fichiers de verrouillage de dépendances ;
• les sommes de contrôle signées ;
• les notes de version.

Ne hachez pas tout sous prétexte que cela existe. Hachez les artefacts qui comptent pour la sécurité, l'audit, la réponse aux incidents, la confiance des clients ou l'intégrité des versions.

Une bonne preuve répond à une question future concrète : « cet artefact ou ce manifeste précis faisait-il partie des preuves de version que nous avons engagées à ce moment-là ? »

Comment fonctionne le regroupement Merkle ?

Pour un seul artefact, une preuve par empreinte suffit.

Pour une version, vous avez généralement de nombreux artefacts, et publier chacun d'eux dans sa propre transaction serait inutilement coûteux. La racine de Merkle résout ce problème. Vous hachez chaque pièce probante en une feuille, vous repliez les feuilles ordonnées en une seule racine de 32 octets, puis vous ne publiez que la racine — un seul record sur la chaîne couvrant l'intégralité de la version.

Le pipeline :

1. construit les artefacts ;
2. génère ou collecte les SBOM, attestations, journaux et manifestes ;
3. hache chaque pièce probante en une feuille ;
4. assemble une liste ordonnée de feuilles ;
5. construit l'arbre de Merkle et calcule la racine ;
6. publie un record Label 309 portant la racine ;
7. stocke la liste de feuilles et les preuves d'inclusion aux côtés des preuves de version.

Plus tard, un vérificateur prend un fichier ou une empreinte, contrôle sa preuve d'inclusion et confirme que l'élément appartient à la racine inscrite dans le record Label 309. La preuve d'inclusion ne croît qu'avec le logarithme de la taille du lot : une racine portant sur des milliers de feuilles se vérifie donc encore en quelques millisecondes — entièrement hors ligne, sans gateway et sans réseau. Pour la mécanique complète, voir un seul record pour des milliers de fichiers.

Pourquoi ne pas se contenter des attestations existantes ?

Utilisez les attestations existantes — puis ancrez-les.

La provenance SLSA décrit où, quand et comment un artefact logiciel a été produit. GitHub Artifact Attestations établit la provenance de build pour des artefacts tels que les binaires et les images de conteneur. Sigstore consigne des métadonnées de chaîne d'approvisionnement signées dans un journal de transparence public et en ajout seul appelé Rekor. in-toto est un cadre qui permet de vérifier que chaque étape d'une chaîne d'approvisionnement a été exécutée comme prévu, par la bonne partie, sur les bonnes entrées.

Chacun de ces outils résout un vrai problème. Label 309 en résout un autre : publier une preuve ancrée sur Cardano et vérifiable de façon indépendante, qu'un ensemble de preuves précis existait avant une heure publique donnée. Un pipeline robuste ne choisit pas entre « attestations ou preuve d'existence ». Il utilise les deux :

• SLSA ou les attestations GitHub pour la provenance de build ;
• Sigstore pour les flux de signature et de journal de transparence ;
• in-toto pour la vérification des étapes de la chaîne d'approvisionnement ;
• Label 309 pour un point d'ancrage temporel public sur l'ensemble des preuves.

Qu'ajoute Label 309 par-dessus ?

Il ajoute un engagement public et durable sur Cardano.

Cet engagement peut couvrir un seul manifeste de version ou une racine de Merkle portant sur de nombreuses pièces probantes. Il peut être signé par l'identité d'un projet ou d'une entreprise. Et il peut être vérifié à partir des seules métadonnées de la transaction et d'un explorateur Cardano public — sans compte, sans connexion, et sans dépendre du fait que le tableau de bord du fournisseur CI d'origine reste en ligne.

Cette indépendance compte surtout lorsqu'une équipe doit prouver que les preuves existaient avant un événement ultérieur :

• une divulgation de vulnérabilité ;
• un incident de sécurité ;
• une revue de sécurité client ;
• un audit des achats ;
• une échéance de conformité ;
• un litige sur une version ;
• une enquête sur la chaîne d'approvisionnement.

La preuve donne à la chronologie un point d'ancrage qu'aucune des parties concernées ne peut déplacer en douce.

Que vérifierait un auditeur ?

Un auditeur doit pouvoir remonter la chaîne depuis un seul artefact jusqu'au record sur la chaîne :

1. prendre l'artefact ou le SBOM examiné ;
2. en calculer l'empreinte ;
3. contrôler la preuve d'inclusion par rapport à la racine de Merkle de la version ;
4. confirmer que la racine apparaît dans un record Label 309 ;
5. retrouver la transaction Cardano et lire son heure de bloc ;
6. vérifier toute signature du record ;
7. contrôler la provenance ou l'attestation environnante selon ses propres règles.

Cela sépare proprement deux questions. La preuve Label 309 répond à : ces preuves ont-elles été engagées à cette heure publique ? La couche SLSA, Sigstore, GitHub ou in-toto répond à : que disent ces preuves sur la façon dont l'artefact a été construit, signé ou distribué ? Ni l'une ni l'autre ne cherche à faire le travail de la seconde.

Que doit contenir le manifeste de version ?

Un manifeste de version doit être ennuyeux et complet. Il peut inclure :

• le nom de la version et son numéro ;
• l'URL du dépôt ;
• le commit source ;
• l'identifiant du workflow de build ;
• l'identifiant d'invocation du build ;
• les noms et empreintes des artefacts ;
• les empreintes des images de conteneur ;
• les empreintes des fichiers SBOM ;
• les empreintes des fichiers d'attestation ;
• les empreintes des rapports de test ;
• l'empreinte du journal de build ;
• l'horodatage rapporté par le système CI ;
• la référence de transaction Label 309, ajoutée après la publication.

Le manifeste lui-même peut être haché et inclus comme une feuille. Il fait aussi office d'index lisible par un humain qui explique chacune des autres feuilles du lot. Gardez le format stable : une preuve est plus facile à vérifier lorsque la structure des preuves est prévisible d'une version à l'autre.

Le pipeline doit-il signer le record ?

En général, oui.

Une racine de Merkle prouve qu'une liste a été engagée. Une signature montre en outre qu'un projet, une entreprise, un système de version ou une identité approuvée s'est porté garant de cet engagement. Dans Label 309, il s'agit d'une signature au niveau du record, optionnelle — la paternité n'est jamais requise pour que l'affirmation d'existence se vérifie, mais elle reste disponible lorsque vous souhaitez établir une responsabilité.

Gérez la clé de signature avec discernement. Ne dispersez pas des graines d'identité à longue durée de vie sur des runners CI arbitraires. Selon votre modèle de menace, utilisez une identité de version dédiée, un service de signature contrôlé, un workflow adossé à du matériel, ou un runner auto-hébergé avec des contrôles d'accès stricts. La CLI cardanowall open source est conçue exactement pour cela — indépendante du gateway et fondée sur la graine brute, elle s'intègre à l'automatisation sans qu'un site web soit dans la boucle. Voir utiliser la CLI dans l'automatisation pour le flux de bout en bout.

Une signature ajoute de la responsabilité. À elle seule, elle ne sécurise pas un pipeline de build défaillant.

Où doit vivre la liste de feuilles ?

Stockez-la avec les preuves de version.

La liste de feuilles et les preuves d'inclusion sont ce qui vous permet de prouver des éléments individuels plus tard. Si vous ne publiez que la racine et que vous perdez ensuite la liste de feuilles, vous pouvez toujours prouver qu'une liste a existé — mais vous risquez de ne plus pouvoir prouver qu'un artefact précis en faisait partie.

Les bonnes options de stockage dépendent du flux de travail :

• l'attacher à l'archive de version ;
• la stocker dans un dépôt d'artefacts ;
• la conserver dans un bucket de preuves interne ;
• la sceller comme contenu chiffré pour des preuves confidentielles ;
• la publier via un stockage adressé par le contenu lorsqu'il est sûr de la rendre publique.

La racine est le point d'ancrage. La liste de feuilles est la carte.

À quelle fréquence un pipeline doit-il publier ?

Alignez la cadence des preuves sur la cadence des versions. Choix courants :

• une preuve par version ;
• une preuve par build ;
• une preuve par déploiement ;
• une preuve par jour pour les journaux continus ;
• une preuve par événement significatif pour la sécurité.

Publier trop rarement affaiblit la chronologie ; publier trop souvent ajoute du coût et du bruit opérationnel. Le regroupement Merkle vous laisse choisir une cadence qui correspond à la question métier. Si un client demande « qu'est-ce qui a été livré exactement dans la version 2.3.1 ? », une preuve par version suffit largement. Si un régulateur ou un auditeur demande si la surveillance était continue, des engagements quotidiens ou horaires servent mieux le propos.

Publier coûte de l'argent, car le gateway paie de vrais frais de transaction Cardano en plus du stockage — la cadence est donc un véritable arbitrage entre coût et preuve, et non un curseur gratuit.

Que ne prouve pas une preuve CI/CD ?

Elle ne prouve pas que le build était sûr.

Une preuve d'existence peut montrer qu'un artefact, un SBOM, un journal ou un manifeste existait à une heure publique donnée ; que l'élément était inclus dans un lot engagé ; et qu'une clé a signé le record. C'est l'ensemble de ce qu'elle certifie.

Elle ne prouve pas que le code source était sûr. Elle ne prouve pas que le runner n'a pas été compromis. Elle ne prouve pas que les dépendances étaient exemptes de vulnérabilités. Elle ne prouve pas que le SBOM est complet. Et elle ne prouve pas qu'une attestation est digne de confiance, sauf si les propres règles de vérification de cette attestation sont respectées. C'est précisément pour cela que Label 309 se place à côté des outils de sécurité de la chaîne d'approvisionnement plutôt que de les remplacer — voir ce qu'une preuve ne prouve pas pour les limites générales.

Quelle est une bonne première mise en œuvre ?

Commencez par une preuve de version. Pour chaque version :

1. générez vos artefacts habituels ;
2. générez ou collectez les SBOM et les attestations ;
3. créez un manifeste de version ;
4. hachez chaque fichier probant en une feuille ;
5. construisez la racine de Merkle ;
6. publiez un record Label 309 signé ;
7. enregistrez la référence de transaction dans les notes de version ;
8. stockez le manifeste, la liste de feuilles et les preuves d'inclusion avec la version.

Cela vous donne une piste probante exploitable sans avoir à réarchitecturer votre système de build dès le premier jour. À partir de là, étendez aux journaux quotidiens, aux manifestes de déploiement ou à une automatisation à plus grand volume.

En résumé

Une preuve CI/CD est un engagement horodaté sur les preuves de version.

Hachez les artefacts, les SBOM, les journaux, les attestations et les manifestes qui comptent. Regroupez-les en une seule racine de Merkle. Publiez cette racine dans un record Label 309. Signez le record si vous voulez qu'une identité de projet ou d'entreprise s'en porte garante.

Conservez SLSA, Sigstore, GitHub Artifact Attestations et in-toto pour la provenance et les métadonnées de chaîne d'approvisionnement. Ajoutez Label 309 comme point d'ancrage temporel public et indépendant qui rattache l'ensemble des preuves à un instant qu'aucun fournisseur ne peut déplacer.

Pour aller plus loin

• Un seul record pour des milliers de fichiers — comment le regroupement Merkle ancre tout un ensemble sous une seule racine.
• Utiliser la CLI dans l'automatisation — piloter la publication et la vérification depuis un pipeline.
• Preuve d'existence ou Sigstore — en quoi les deux couches diffèrent et où elles s'articulent.
• Provenance de build SLSA — la spécification de provenance SLSA.
• Sigstore et le journal de transparence Rekor — la signature sans clé avec un journal public en ajout seul.
• GitHub Artifact Attestations — la provenance de build pour les artefacts construits sur GitHub.
• in-toto — le cadre d'intégrité de la chaîne d'approvisionnement logicielle.