Ce qu’il faut retenir
- Un tag est un nom pratique ; un digest identifie un contenu précis.
- Une empreinte ne démontre ni la sécurité du contenu ni la fiabilité de son constructeur.
- La provenance doit être vérifiée contre une politique de confiance avant de servir de preuve de livraison.
La CI a construit une image, l’exploitation a déployé application:stable et le service répond. Quelques heures plus tard, le tag pointe vers un autre contenu. Que faut-il redéployer pour retrouver exactement la version précédente ? Le nom seul ne répond plus. Une livraison fiable distingue l’identité de l’artefact, les informations sur sa fabrication et le comportement réellement observé.
Le tag aide à parler, le digest aide à comparer
Une image de conteneur possède des métadonnées et des couches. Un digest est une empreinte cryptographique de contenu utilisée pour référencer un objet précis. La documentation Docker sur les digests explique la différence avec les tags, qui peuvent être déplacés. Déployer par digest stabilise la référence, même si le registre propose ensuite une autre version sous le même nom.
Le contexte multiarchitecture demande une précision supplémentaire. Un index peut regrouper des manifestes pour plusieurs plateformes. Son digest et celui du manifeste effectivement sélectionné ne sont pas le même objet. La preuve de livraison indique ce qu’elle compare : référence de l’index, plateforme et image exécutée. Une chaîne de caractères différente n’est pas automatiquement un écart de contenu si l’on compare deux niveaux distincts.
Épingler le digest ne rend pas l’image saine. Cela garantit une identité de contenu sous les hypothèses du mécanisme de hachage et de sa vérification. Une image vulnérable ou malveillante reste la même image lorsqu’on la référence correctement. L’identité est une condition de la maîtrise, pas une conclusion de sécurité.
D’où vient cet artefact ?
La spécification SLSA 1.0 de provenance décrit des informations sur le processus de fabrication : artefact concerné, constructeur et paramètres ou dépendances de build selon le modèle. Ces informations aident à relier un binaire aux conditions de sa production. Leur existence ne prouve pas à elle seule qu’elles sont fiables : il faut contrôler leur authenticité et leur origine.
Une signature indique qu’une identité a signé un contenu. La politique décide si cette identité est acceptable pour ce logiciel et ce contexte. Une attestation signée par un acteur inconnu, ou par le mauvais workflow d’un dépôt connu, ne remplit pas la promesse. Le contrôle vérifie aussi que le sujet de l’attestation correspond au digest de l’image à déployer.
Les choix d’open source pour les PME gagnent à distinguer ces preuves. Le code visible, la version déclarée et l’image disponible au registre ne sont pas automatiquement reliés. Une provenance exploitable réduit cet écart, avec une politique claire sur les constructeurs et les sources autorisés.
Une chaîne de preuve du commit au service
Le build enregistre la révision source et produit l’artefact une fois. La livraison promeut cet artefact vers les environnements au lieu de le reconstruire à chaque étape sous le même numéro. Une reconstruction peut changer une dépendance, l’image de base ou un téléchargement externe. Elle doit être considérée comme un nouvel artefact, même si le code applicatif n’a pas changé.
Le manifeste de déploiement référence le digest approuvé. L’exploitation relit ensuite la version réellement exécutée. Un indicateur de santé confirme que le service répond, puis un test du parcours concerné confirme le comportement. Ces preuves sont complémentaires : un conteneur actif peut encore servir une mauvaise configuration ou échouer sur une route essentielle.
L’immuabilité exige une politique de mise à jour
Épingler toutes les images puis les oublier fige aussi leurs défauts. La politique indique comment recevoir les avis, construire une nouvelle version et la tester. Une SBOM aide à retrouver les composants embarqués. Les déploiements rattachés aux digests permettent d’identifier ceux qui nécessitent une correction. La promotion du nouveau contenu produit une trace et conserve une version précédente compatible pour le retour.
La conservation du registre suit cette fenêtre. Un rollback vers un digest supprimé n’est qu’une ligne dans un document. Les artefacts, attestations et inventaires nécessaires restent disponibles pendant la période annoncée. Les permissions de suppression et de déplacement de tags sont contrôlées ; les noms utiles au quotidien ne doivent pas donner un faux sentiment d’historique immuable.
Un tag déplacé après la validation
Exemple hypothétique : une équipe valide l’image d’un service de facturation puis déploie son digest sha256:…. Une automatisation déplace ensuite le tag stable vers un nouveau build. Le service continue à utiliser l’artefact approuvé. Lors d’une enquête, l’équipe retrouve la révision source, l’exécution de CI et la provenance associées à ce digest. Elle ne tente pas de déduire ces données du tag actuel.
Dans une variante, l’attestation concerne un autre digest ou provient d’un workflow non autorisé. Le contrôle de promotion refuse l’artefact et donne un motif lisible. Le refus ne signifie pas que l’image est nécessairement malveillante ; il signifie que la preuve attendue manque. Une procédure d’exception éventuelle est explicite, limitée et attribuée, au lieu de contourner discrètement la vérification.
Quatre niveaux de preuve distincts
| Preuve | Question résolue | Limite |
|---|---|---|
| Digest | Quel contenu ? | Ne juge pas sa sécurité |
| Provenance vérifiée | Quel processus l’a produit ? | Dépend de la confiance au constructeur |
| État de déploiement | Quel artefact est exécuté ? | Ne prouve pas le parcours utilisateur |
| Test fonctionnel | Le service réalise-t-il l’usage attendu ? | Ne couvre pas toutes les entrées possibles |
La preuve du build ne connaît pas toute la production
Les secrets, paramètres, volumes et dépendances externes peuvent changer sans changer l’image. Un même digest peut se comporter différemment dans deux environnements. La traçabilité associe donc aussi la configuration nécessaire, avec les protections adaptées aux secrets. Elle ne stocke pas leurs valeurs dans un inventaire public simplement pour compléter une fiche.
Un constructeur compromis peut produire un artefact et une provenance cohérente avec ses propres déclarations. L’isolation de la CI, les droits des jobs et la revue des workflows restent nécessaires. Les principes de réduction des privilèges s’appliquent à ce constructeur comme aux agents d’exécution. L’attestation rend certains contrôles possibles ; elle ne remplace pas leur politique.
Faire échouer volontairement la promotion
La recette accepte un artefact attendu, puis teste un digest sans attestation, une identité de signature non autorisée et une provenance portant sur une autre image. Elle vérifie que le contrôle fonctionne dans le véritable chemin de livraison et produit un diagnostic compréhensible. Un script facultatif que chacun peut ignorer n’établit pas une règle de promotion.
Le contrôle du registre, de la CI et du service relève des intégrations entre outils. Les reprises et erreurs doivent être visibles. La prochaine action consiste à prendre un service actif et à retrouver son digest, sa provenance vérifiée et sa révision source. Si cette relation ne peut pas être démontrée, le tag commercial ne suffit pas à appeler la livraison traçable.
Sources et références
Mise à jour du 1er octobre 2026 : références vérifiées à cette date. Les mécanismes décrits sont durables ; les options exactes restent à vérifier dans la version du produit utilisée.
- Docker — Image digests — identité de contenu et différence avec les tags
- SLSA 1.0 — Provenance (2023) — description de la fabrication et rattachement à l’artefact
