Une connexion SSH qui consomme trop de processeur, un développeur intrigué, puis la découverte d’un sabotage préparé dans l’ombre : l’affaire XZ a rappelé combien une infrastructure mondiale peut dépendre d’un détail remarqué à temps. En ce mois de septembre 2026, elle reste une grille de lecture pour examiner les protections de la chaîne logicielle. Non parce que tous les projets libres seraient suspects, mais parce qu’un inventaire impeccable ou une signature valide ne suffisent pas à rendre un composant digne de confiance.
XZ, ou l’attaque qui a emprunté le chemin normal
Le 29 mars 2024, Andres Freund, développeur chez Microsoft et contributeur à PostgreSQL, révèle une porte dérobée dans XZ Utils, ensemble d’outils de compression très répandu sous Linux. Les versions 5.6.0 et 5.6.1 sont concernées. L’attaque vise, sous certaines conditions, le fonctionnement du serveur SSH : une bibliothèque de compression devient ainsi un point d’entrée potentiel vers un service d’accès distant.
Le détour compte. Sur certaines distributions, le serveur SSH se retrouvait lié indirectement à liblzma, la bibliothèque de XZ, notamment par l’intermédiaire de libsystemd. L’exploitation dépendait aussi de conditions de compilation et d’environnement précises. Dire que « Linux était compromis » serait donc trompeur. Des branches de développement ou de test de distributions avaient intégré les versions affectées, mais de nombreuses versions stables largement déployées n’étaient pas concernées.
La sophistication ne tenait pas seulement au code. Un compte connu sous le nom de Jia Tan avait progressivement acquis des responsabilités dans le projet. Des messages publics avaient parallèlement accru la pression sur son mainteneur historique. L’identité réelle et l’organisation derrière l’opération ne sont pas établies publiquement avec certitude. La leçon, elle, est claire : l’attaquant avait travaillé à devenir un acteur légitime du processus.
L’inventaire : indispensable pour chercher, insuffisant pour juger
Premier réflexe après une alerte : savons-nous où se trouve le composant ? La nomenclature logicielle, ou SBOM, répond à cette question. Elle décrit les ingrédients d’un produit : bibliothèques, versions, relations de dépendance. Des formats comme SPDX et CycloneDX permettent de partager ces informations sans tout réinventer entre fournisseur, client et équipe de sécurité.
Dans un incident comme XZ, un inventaire exploitable réduit le temps passé à fouiller des machines, images de conteneurs ou appliances. Encore faut-il qu’il corresponde à ce qui est réellement livré. Un SBOM généré sur le dépôt source peut manquer une bibliothèque ajoutée pendant la construction. Celui d’une image initiale ne décrit pas nécessairement un serveur modifié depuis son déploiement.
Le SBOM est une carte, pas un certificat d’innocuité. Il peut signaler la présence d’une version vulnérable une fois l’alerte connue ; il ne révèle pas spontanément une porte dérobée inconnue. Il faut aussi interpréter le contexte : composant installé, chargé, accessible, ou utilisé dans les conditions nécessaires à l’attaque. Sans cette analyse, l’inventaire produit surtout des listes alarmantes et des tickets en série.
Une signature garantit une origine, pas une intention
Deuxième promesse souvent mal comprise : « le paquet est signé ». Une signature cryptographique permet de vérifier qu’un contenu n’a pas été modifié depuis sa signature et qu’il est associé à une clé donnée. C’est essentiel contre la substitution d’un téléchargement ou d’un paquet. Mais si la personne autorisée publie volontairement un contenu piégé, la vérification peut parfaitement réussir.
XZ illustre cette limite : la menace ne venait pas simplement d’un miroir de téléchargement compromis. Elle s’inscrivait dans la fabrication et la publication d’une version. Vérifier davantage de signatures sans revoir qui peut publier, selon quelles règles et avec quel contrôle indépendant aurait donc laissé subsister une partie centrale du problème.
Des approches comme Sigstore facilitent la signature et sa traçabilité, notamment en l’associant à des identités et à des journaux de transparence. Elles rendent certaines manipulations plus visibles. Mais leur valeur dépend de la politique appliquée : quelle identité accepte-t-on ? Quel workflow est autorisé ? Qui peut le modifier ? Une signature n’est utile que si la confiance accordée à son signataire est maîtrisée.
Compiler ce que l’on a vraiment examiné
Le point le plus instructif de XZ se situe entre le code consultable et le binaire distribué. L’attaque combinait notamment des fichiers de test présents dans le dépôt et une logique malveillante introduite dans les archives sources publiées, les tarballs. Examiner uniquement le dépôt ne revenait donc pas à examiner exactement les entrées de la compilation effectuée en aval.
Première conséquence pratique : traiter la fabrication de l’archive de publication comme une étape sensible. Il faut pouvoir relier le dépôt, la révision retenue, les fichiers générés et l’archive livrée. Les scripts de configuration, rarement lus avec autant d’attention que le code principal, méritent aussi une revue. Un fichier présenté comme une donnée de test n’est pas nécessairement inoffensif.
Reproductibilité et provenance : deux preuves différentes
Une compilation reproductible permet à des acteurs indépendants d’obtenir un résultat identique à partir des mêmes sources et d’un environnement défini. Elle aide à repérer un binaire ne correspondant pas aux entrées annoncées. En revanche, si ces entrées contiennent déjà le sabotage, reproduire fidèlement le résultat reproduit aussi le problème. La comparaison entre dépôt et archive publiée reste donc cruciale.
La provenance documente plutôt le parcours : quelles sources, quel système de construction, quelles étapes ? Des cadres comme SLSA structurent ces garanties ; des attestations peuvent rendre ce parcours vérifiable automatiquement. Mais une attestation issue d’un constructeur compromis, ou acceptée sans vérifier son identité, peut donner une assurance trompeuse. Il faut protéger la chaîne de preuve autant que la chaîne de compilation.
La sécurité se joue aussi dans l’organisation
XZ n’appelle pas à exiger de chaque petit projet une bureaucratie industrielle. Cela pourrait épuiser les mainteneurs que l’on prétend aider. La réponse doit être proportionnée à la criticité : nombre de produits dépendants, privilèges du composant, exposition réseau, difficulté de remplacement. Les entreprises qui bénéficient d’une brique essentielle ont intérêt à financer du temps de maintenance, des revues et une relève crédible.
Pour une équipe informatique, quatre priorités concrètes se dégagent :
- Inventorier le livré, avec des identifiants exploitables et une mise à jour liée aux versions réellement déployées.
- Contrôler les publications, en séparant les responsabilités et en imposant une revue indépendante des changements sensibles.
- Vérifier la construction, en rapprochant dépôt, archive, attestations et binaires, avec des reconstructions indépendantes lorsque c’est pertinent.
- Préparer le retrait, avec une procédure testée pour bloquer une version, reconstruire les produits touchés et distribuer rapidement les correctifs.
Et maintenant ? L’évolution souhaitable, au-delà de septembre 2026, serait de passer de documents accumulés à des preuves effectivement contrôlées avant déploiement. Les achats logiciels pourraient davantage valoriser cette capacité de vérification, plutôt que la simple présence d’un SBOM. Ce progrès reste conditionnel : il demandera des outils interopérables, des moyens humains et des responsabilités explicites. La leçon de XZ n’est pas de supprimer la confiance, mais de faire en sorte qu’aucune confiance solitaire ne suffise à compromettre toute la chaîne.
