Comment intégrer la signature de code ML-DSA au CI/CD en 2026 ?

Le repère à retenir avant toute modification

Le NIST a publié FIPS 204 le 13 août 2024 : ce document normalise ML-DSA comme algorithme de signature numérique. Cette date et cette normalisation ne prouvent toutefois pas que votre outil de construction, votre format d’artefact et chaque client de déploiement savent déjà le traiter. Pour intégrer la signature de code ML-DSA en CI/CD, commencez donc par un pilote isolé qui vérifie les clés, la signature, la validation côté consommateur et les conditions de retour arrière avant toute extension. Le texte officiel de FIPS 204 définit le standard, pas la compatibilité de toute votre chaîne logicielle.

Cet article s’adresse aux ingénieurs DevSecOps qui signent des artefacts, aux responsables des infrastructures de publication qui doivent coordonner signature et vérification, ainsi qu’aux responsables sécurité qui préparent une migration post-quantique.
Si vous cherchez uniquement une présentation théorique des algorithmes, concentrez-vous plutôt sur les étapes d’intégration et les critères de décision ci-dessous.

Préparer le périmètre et la confiance

Avant de choisir une bibliothèque ou d’ajouter une étape à votre pipeline, écrivez précisément ce qui doit être signé. Un paquet installable, une image de conteneur, un programme de mise à jour et une archive de livraison peuvent avoir des formats, des consommateurs et des processus de publication différents. Une signature attachée au mauvais objet ne protège pas la livraison attendue : vous pourriez signer une archive temporaire alors que le déploiement consomme un paquet reconstruit ensuite.

Tracez ensuite le chemin de confiance. Il doit montrer qui produit l’artefact, quel service ou processus détient l’autorisation de signer, où la signature est publiée et quel composant la vérifie avant installation ou exécution. Identifiez également les cas où un intermédiaire copie, transforme ou reconditionne l’artefact : une transformation après signature peut invalider la vérification, même si elle est prévue par le processus opérationnel.

FIPS 204 est la référence normative pour ML-DSA. Il faut la distinguer de trois autres éléments qui ne sont pas automatiquement couverts par le standard :

• L’implémentation cryptographique : la bibliothèque et sa version doivent exposer une prise en charge adaptée à votre usage.
• Le format de l’artefact signé : il détermine comment la signature, la clé publique et les informations de vérification sont encodées ou associées.
• Les outils des consommateurs : installateurs, agents de mise à jour, registres ou scripts de déploiement doivent reconnaître cette combinaison.

Par exemple, la documentation d’OpenSSL sur son interface de signature ML-DSA concerne cette bibliothèque et cette interface ; elle ne démontre pas que votre format de paquet ou vos clients acceptent ce mécanisme. Vérifiez la documentation correspondant exactement à la bibliothèque et à la version que vous envisagez, puis confirmez séparément le support du format et des outils de consommation.

Pour garder une trace vérifiable du lien entre la construction et la livraison, définissez les éléments d’audit que vous conserverez : identité de construction, révision source, condensat de l’artefact, identité de la clé ou référence de clé, résultat de vérification et décision de publication. Une attestation de provenance décrit des informations sur la production d’un artefact ; elle ne remplace pas la signature de celui-ci. La spécification de provenance SLSA peut vous aider à distinguer ces deux fonctions.

Concevoir les clés et les autorisations

Le choix du mécanisme de stockage ne se résume pas à « mettre la clé dans le coffre de la plateforme ». Vous devez décider qui peut demander une signature, dans quelles circonstances la demande est acceptée, comment les opérations sont auditées et ce qui se passe si une clé doit être remplacée ou révoquée. Séparez autant que possible le droit de construire du droit de signer : un processus compromis qui peut modifier le code ne devrait pas obtenir implicitement une autorisation illimitée de publication.

Définissez les règles avant de configurer les secrets :

• Où la clé privée est-elle générée et conservée ?
• Quels identifiants permettent au processus de signature d’y accéder ?
• L’accès est-il limité à un projet, une branche protégée, une étape de livraison ou une identité de service précise ?
• Qui peut créer, renouveler, désactiver ou révoquer la clé ?
• Que doivent faire les consommateurs lorsqu’une clé est retirée, mais qu’un artefact déjà publié doit encore être vérifié ?

Ne recopiez pas ces choix sous la forme de commandes génériques : les noms d’options, les mécanismes de stockage et les contrôles d’accès diffèrent selon les produits. Appuyez-vous sur la documentation officielle de la solution réellement retenue et testez la configuration avec des identifiants sans privilège de production.

Un secret de pipeline ne doit jamais apparaître dans le dépôt, dans une sortie de débogage ou dans un journal accessible aux utilisateurs qui n’ont pas besoin de le connaître. La documentation sur la gestion des secrets dans les flux de travail automatisés rappelle les contrôles propres à cette plateforme ; transposée à votre environnement, la leçon est de vérifier à la fois les droits d’accès et les chemins indirects d’exposition. Masquer une valeur dans l’interface ne suffit pas si une commande la réimprime ou si un processus enfant peut la lire.

Point de vigilance : ne publiez jamais une clé privée pour faciliter la vérification. Le consommateur a besoin de la clé publique et d’une règle permettant de savoir pourquoi cette clé est approuvée ; votre équipe doit, elle, protéger l’accès à la clé de signature et tracer son usage.

Intégrer la signature à la livraison

Une étape de signature utile doit être liée à l’artefact réellement distribué, à son origine et à la décision de publication. Si le pipeline signe un fichier, puis qu’une étape ultérieure le modifie ou le reconstruit, la signature ne décrit plus nécessairement ce que reçoit le consommateur. Choisissez donc le point de signature après la dernière transformation pertinente, ou formalisez explicitement chaque objet signé et son rôle.

Le processus devrait enregistrer au minimum le condensat exact de l’artefact, la révision source, l’identité du processus de construction, la référence de la clé utilisée et le résultat de la vérification. Ces informations permettent de répondre à une question opérationnelle souvent négligée : « Quel artefact cette signature autorisait-elle à publier ? » Une signature valide, isolée de son contexte, ne suffit pas toujours à établir que le fichier provient du processus attendu.

Évitez également de faire dépendre l’autorisation de signer d’un simple nom de branche ou d’une variable modifiable par un contributeur. Il faut définir quelles conditions sont contrôlées par la plateforme et lesquelles doivent être établies par votre organisation, puis confirmer que les exceptions — publication d’urgence, reconstruction ou livraison manuelle — apparaissent dans l’audit.

Pendant le pilote, conservez les résultats de test sans inclure de secret : identifiant de construction, condensat, référence de clé, format de signature, vérification réussie ou refusée, et version du vérificateur. Si votre format transporte des attestations ou des enveloppes, vérifiez son comportement avec vos consommateurs plutôt que de supposer qu’un format standardisé par une bibliothèque sera interprété uniformément. Le projet DSSE décrit une enveloppe pour des objets signés, mais son adoption et sa compatibilité doivent aussi être établies dans votre chaîne réelle.

Vérifier la signature du point de vue du consommateur

Ne validez pas uniquement la commande de signature. Le test doit inclure l’outil qui vérifiera les artefacts dans l’environnement de déploiement, de mise à jour ou d’installation. Un test réussi sur le poste du développeur ne prouve pas que le client déployé dispose de la même bibliothèque, du même format ou des mêmes paramètres de confiance.

Pour chaque chemin de consommation retenu, exécutez des cas distincts :

• un artefact intact signé par la clé attendue doit être accepté ;
• une modification du contenu après signature doit provoquer un refus ;
• une clé publique qui ne correspond pas à la signature doit provoquer un refus ;
• une signature absente, tronquée ou mal encodée doit échouer sans être assimilée à une vérification réussie ;
• une clé révoquée ou retirée doit suivre la politique documentée par votre équipe.

Ces cas ne sont pas interchangeables. En particulier, un client peut refuser correctement une signature inconnue sans savoir distinguer une clé malveillante d’une clé simplement absente de son magasin de confiance. Votre procédure doit donc séparer la validation cryptographique de la décision organisationnelle d’approuver une clé.

Faites aussi des essais dans les environnements représentatifs du déploiement : système de construction, registre d’artefacts, miroir, agent de mise à jour et outil d’installation. Notez les versions et configurations réellement testées, sans étendre la conclusion à des environnements non vérifiés. Les exigences de migration post-quantique dépassent par ailleurs le seul choix d’un algorithme : la foire aux questions du NCCoE sur la migration vers la cryptographie post-quantique constitue un point de départ pour inventorier les dépendances et planifier la transition. Consultez aussi le guide de tests de migration du NCCoE lorsque vous préparez votre campagne de validation.

Décider du pilote et de son retour arrière

Commencez par un artefact non critique dont vous maîtrisez le cycle de vie et les consommateurs. Faites coexister le chemin d’essai avec le processus de confiance déjà approuvé : l’objectif est de vérifier la compatibilité sans rendre une publication de production dépendante d’une prise en charge non confirmée. Pendant cette période, relevez les refus, les erreurs de format, les limites des clients et les tâches manuelles ajoutées au processus.

La migration post-quantique ne signifie pas que vous devez retirer immédiatement chaque mécanisme existant. Elle exige plutôt de savoir où la nouvelle signature est produite, où elle est vérifiée et quelle équipe prend en charge les composants incompatibles. Faites l’inventaire des clients anciens, des outils de récupération, des miroirs et des procédures de restauration ; les consommateurs rarement utilisés sont souvent ceux qui échappent aux premiers essais.

Votre règle de décision

• Si tous les consommateurs prévus vérifient l’artefact signé, que l’identité de construction est traçable et que la clé est protégée par des autorisations contrôlées, alors élargissez le pilote par catégories de produits, en conservant les résultats de vérification.
• Si un consommateur important ne reconnaît pas ML-DSA ou le format choisi, alors suspendez l’extension et maintenez le chemin de signature déjà approuvé pour cette catégorie. Ne contournez pas l’échec en désactivant la vérification.
• Si la clé ou les autorisations sont exposées, ou si vous ne pouvez pas relier la signature à l’artefact publié, alors bloquez la promotion, préservez les journaux et appliquez le plan de révocation ou de remplacement défini par votre équipe.
• Si l’échec provient seulement d’un composant de test isolé et qu’un chemin de publication sûr reste disponible, alors corrigez le composant et recommencez le pilote avant de modifier la politique de production.

Avant le lancement, cochez chaque point qui s’applique :

• [ ] L’objet exact à signer et les étapes de transformation sont documentés.
• [ ] La bibliothèque, sa version et le format de signature ont été vérifiés dans leurs documentations officielles.
• [ ] La clé privée est séparée du dépôt, des journaux et des accès non nécessaires.
• [ ] La signature est reliée au condensat et à l’identité de construction de l’artefact livré.
• [ ] Les vérificateurs des consommateurs ont été testés, y compris avec des artefacts altérés et des clés incorrectes.
• [ ] Le comportement des anciens clients, des miroirs et des mécanismes de mise à jour est connu.
• [ ] Une personne responsable peut arrêter la publication et déclencher le retour au processus approuvé.
• [ ] Les versions et limites réellement testées sont consignées, sans présenter une compatibilité supposée comme acquise.

Questions fréquentes

ML-DSA convient-il à la signature des artefacts logiciels ?

Oui, ML-DSA est un algorithme de signature numérique normalisé par FIPS 204 et peut donc servir à signer des artefacts, à condition que l’implémentation, le format de signature et les outils du consommateur soient compatibles. Le standard ne certifie pas à lui seul votre chaîne de publication : vous devez vérifier la prise en charge de bout en bout et définir quelle identité est autorisée à signer.

Comment vérifier la signature ML-DSA dans une chaîne CI/CD ?

Commencez par créer un artefact d’essai dans un environnement isolé, associez sa signature à son condensat et à l’identité de construction, puis vérifiez-le avec l’outil réellement utilisé par le consommateur. Testez aussi un artefact modifié, une clé publique incorrecte et une signature mal formée. Les commandes et options dépendent de la bibliothèque et de son édition : suivez sa documentation officielle.

Les anciens clients pourront-ils vérifier les signatures après la migration ?

Pas nécessairement. Un client qui ne reconnaît pas l’algorithme, le format d’encodage ou le conteneur de signature ne pourra pas vérifier un artefact ML-DSA, même si la signature est valide. Avant toute bascule, testez les versions encore déployées, les environnements de mise à jour et les miroirs de paquets. Conservez une voie de publication précédente tant que ces consommateurs ne sont pas identifiés.

Quels critères justifient le retour arrière d’un pilote ML-DSA ?

Arrêtez la promotion si une catégorie de consommateur prévue ne sait pas vérifier la signature, si la clé de signature est exposée ou si l’identité de construction ne peut pas être reliée à l’artefact publié. Le retour arrière doit restaurer le processus de confiance déjà approuvé, sans effacer les journaux ni accepter silencieusement un artefact non vérifié. Documentez à l’avance qui peut autoriser la reprise.

Choisir l’environnement de test sans supposer la compatibilité

Un agent de construction déjà en place peut être le meilleur choix si vous devez reproduire fidèlement une chaîne de production stable, notamment lorsque ses dépendances matérielles ou ses interfaces locales sont indispensables. En revanche, un environnement partagé ou difficile à isoler peut compliquer les essais de clés, les changements de configuration et la collecte de journaux. Une machine temporaire apporte un espace de test séparé, mais ajoute ses propres tâches : préparer l’environnement, installer les outils approuvés, contrôler les accès et détruire les secrets temporaires après l’essai.

Un Mac ne rend pas ML-DSA compatible par lui-même. La compatibilité dépend toujours de la bibliothèque, de sa version, du format et des clients que vous avez retenus. Pour un pilote nécessitant un environnement macOS ou une validation de chaîne créative — par exemple un projet audio, vidéo ou de conception dont les outils de livraison sont propres à cette plateforme — une machine dédiée peut toutefois éviter de modifier un poste de travail ou un agent partagé. Si vous évaluez cette option, consultez les informations sur la location de Mac mini, puis confirmez séparément que votre pile cryptographique est prise en charge.

Louer une machine de test est moins pertinent si votre besoin est une charge de production permanente, un contrôle physique particulier ou une dépendance matérielle qu’un environnement distant ne peut pas fournir. À l’inverse, si votre approche actuelle repose sur un agent partagé, elle peut exposer les essais à des permissions héritées, rendre la remise à zéro plus délicate et brouiller la séparation entre test et livraison. Un environnement Mac loué par ZavCloud peut alors servir à isoler une reproduction temporaire et à contrôler le comportement de vos outils, sans prétendre valider une compatibilité ML-DSA qui n’a pas été vérifiée. Avant de réserver, examinez les informations d’assistance de ZavCloud et comparez-les aux exigences de votre pipeline.