Guide · Continuum Attest
Provenance de build : relier les artefacts à leur fabrication
La provenance de build décrit comment un artefact logiciel a été produit. Continuum Attest matérialise cette information dans un reçu signé, conservé avec la livraison.
Ce que décrit une provenance
Une archive service.tar.gz donne accès au logiciel. Son nom et son numéro de version n’expliquent pas les commandes exécutées ni les fichiers utilisés pour la fabriquer. La build provenance apporte ce contexte : exécution, entrées déclarées, étapes et résultats.
Dans Continuum Attest, le fichier attest.yaml fixe le périmètre enregistré. Le CLI calcule les empreintes des entrées et sorties déclarées, exécute les étapes et consigne leurs résultats. La signature est demandée explicitement avec attest run --sign.
Un exemple de périmètre utile
Pour un service compilé, déclarez le code source, le manifeste des dépendances et son fichier de verrouillage en entrée ; déclarez le binaire livré en sortie. Incluez aussi les scripts de fabrication qui influencent le résultat. Un fichier lu mais non déclaré échappe à ce périmètre.
Une provenance exploitable commence donc par une description exacte du build. Accumuler des journaux sans identifier les artefacts correspondants rend leur interprétation plus difficile.
De la provenance au reçu signé
La provenance est l’information sur la fabrication. La signature lie le reçu à une clé et permet de détecter sa modification. Le destinataire choisit indépendamment les clés auxquelles il fait confiance, puis vérifie le reçu et les fichiers disponibles.
La signature ne rend pas exact un enregistrement incomplet ou mensonger. Elle permet de contrôler l’intégrité de la déclaration. La fiabilité du processus qui produit cette déclaration reste une question distincte.
Formats et vérification
L’export in-toto de Continuum Attest transporte la provenance dans un Statement v1 avec un prédicat SLSA Provenance v1. Ce format ne constitue pas, à lui seul, la preuve d’un niveau SLSA.
Consultez le format du reçu pour les champs signés, puis la documentation CLI pour produire votre premier reçu. L’article Trust is not evidence explique pourquoi le statut du pipeline ne remplace pas cette preuve portable.
Référence : SLSA Build Provenance.