in-toto et les reçus signés Continuum Attest

Trois couches à distinguer

Le Statement relie une déclaration à des artefacts identifiés par leurs empreintes. Le prédicat exprime le contenu de cette déclaration. L’enveloppe DSSE porte les données signées et leurs signatures.

Cette séparation aide un outil destinataire à reconnaître le document, identifier son sujet et interpréter sa provenance. Elle n’oblige pas le destinataire à utiliser la même interface que le producteur.

Exporter un reçu

Après avoir créé le reçu et préparé les clés nécessaires, utilisez :

attest export --receipt receipt.yaml --format in-toto --output statement.json

La documentation CLI décrit les commandes d’export et d’import. Le format du reçu reste la référence du document natif et des informations qu’il contient.

Vérifier l’interopérabilité concrète

Pour un outil destinataire, vérifiez la version du Statement, le type de prédicat, les algorithmes pris en charge et la manière dont les clés sont approuvées. Un fichier JSON lisible ne prouve pas que sa signature a été contrôlée.

Un bon essai utilise un artefact et son attestation, puis répète la vérification après modification du fichier ou de la déclaration. Le résultat doit indiquer précisément quel contrôle a échoué.

SLSA et Sigstore dans cet ensemble

SLSA définit notamment un format de provenance et des exigences graduées concernant la chaîne de production. Émettre un prédicat SLSA ne démontre pas l’atteinte d’un niveau. Sigstore propose des outils et services de signature et de vérification ; ce nom ne désigne pas le contenu de la provenance.

L’article in-toto, SLSA, Sigstore : qui fait quoi ? détaille leurs rôles. Le guide SBOM vs attestation situe les documents complémentaires.

Références : spécifications in-toto et SLSA 1.2.