Attestation d’artefact : signer une déclaration vérifiable

Identifier l’artefact avant de lire la déclaration

Deux fichiers peuvent porter le même nom tout en contenant des octets différents. Pour relier une attestation au bon artefact, il faut une empreinte calculée selon les règles du format concerné. Un numéro de release ne suffit pas.

L’attestation apporte ensuite une déclaration : comment le fichier a été produit, par exemple. Sa signature permet de vérifier l’intégrité de cette déclaration et son lien à une clé approuvée.

Les questions à poser

• Quel artefact et quelle empreinte la déclaration concernent-ils ?
• Quelles étapes et quelles entrées sont enregistrées ?
• Quelle clé a signé, et pourquoi le destinataire lui fait-il confiance ?
• Dispose-t-on des fichiers nécessaires à la comparaison ?

Ces questions évitent de confondre un fichier d’attestation présent dans une archive avec une attestation effectivement vérifiée.

Le reçu Continuum Attest

Le CLI enregistre les étapes du build et les empreintes du périmètre déclaré. Avec la signature activée, ce reçu devient une preuve portable : le destinataire peut en contrôler la signature avec son propre magasin de confiance.

Pour comparer les fichiers au reçu, il faut également disposer des fichiers concernés et utiliser les contrôles adaptés. Vérifier uniquement la signature n’examine pas automatiquement chaque fichier livré. La documentation CLI distingue les options de vérification.

Attestation, SBOM et provenance

Une SBOM décrit la composition du logiciel. La provenance décrit sa fabrication. Une attestation porte une déclaration sur un artefact. Ces notions se complètent ; une attestation peut notamment transporter une provenance.

Consultez SBOM vs attestation pour choisir les documents à conserver, puis le format du reçu pour connaître le contenu signé. Le format d’échange in-toto permet d’identifier les artefacts et le type de déclaration sans imposer une interface de plateforme.

Référence : in-toto Statement v1.