Une connexion SSH un peu trop lente, une consommation de processeur inhabituelle : c’est par ces détails qu’une porte dérobée a été découverte dans XZ Utils, au printemps 2024. Pas par un grand audit, mais grâce à l’attention d’un ingénieur. L’épisode pose une question toujours décisive pour envisager septembre 2026 : comment sécuriser les briques gratuites dont dépendent des activités à plusieurs milliards ? Les faits établis éclairent le problème ; les perspectives présentées ici ne préjugent pas des évolutions intervenues depuis.
XZ : une attaque contre le code, mais surtout contre la confiance
Le 29 mars 2024, Andres Freund, ingénieur chez Microsoft, révèle une compromission touchant les versions 5.6.0 et 5.6.1 de XZ Utils. Cette suite d’outils de compression fournit notamment la bibliothèque liblzma. Dans certaines configurations Linux, celle-ci pouvait être chargée indirectement par le serveur SSH via une dépendance à systemd. L’attaque cherchait à détourner cette chaîne pour compromettre l’authentification distante.
Les versions piégées avaient atteint des distributions de développement ou de test, sans s’être généralisées aux principales versions stables. La découverte précoce a donc fortement limité l’exposition. Mais le mécanisme était sophistiqué : certains éléments malveillants étaient dissimulés dans des fichiers de test, puis activés lors de la construction du logiciel sous des conditions précises.
La personne utilisant le pseudonyme Jia Tan avait progressivement gagné des responsabilités dans le projet. Des messages publics faisaient parallèlement pression sur le mainteneur historique pour accélérer les changements. L’identité réelle et l’attribution de l’opération n’étaient pas établies lors de sa révélation. La leçon, elle, était nette : une contribution régulière et une réputation acquise ne constituent pas une preuve d’innocuité.
Le véritable angle mort : le temps des mainteneurs
Une dépendance devient critique non parce qu’elle est célèbre, mais parce qu’elle se retrouve partout. Une bibliothèque de compression, un analyseur de fichiers ou un module d’authentification peuvent irriguer des milliers de produits sans que leurs utilisateurs finaux connaissent leur nom. Dans l’entreprise, quelqu’un achète le service cloud ; personne n’a nécessairement identifié celui qui entretient la petite bibliothèque embarquée.
Or maintenir n’est pas seulement écrire du code. C’est trier les signalements, reproduire des bugs, vérifier les contributions, gérer les publications et répondre aux alertes de sécurité. Ce travail répétitif se prête mal aux annonces spectaculaires. Un financeur préfère souvent soutenir une fonctionnalité visible plutôt que payer six mois de revue attentive et de nettoyage.
Le bénévolat n’est pas synonyme d’insécurité, et le salariat ne protège pas de toute compromission. Mais l’épuisement réduit les marges de contrôle. Quand une seule personne tient le projet, l’arrivée d’un contributeur disponible peut sembler providentielle. Financer une seconde paire d’yeux, c’est aussi réduire la dépendance à une relation de confiance unique.
Qui doit payer cette infrastructure commune ?
Les bénéficiaires les plus évidents sont les entreprises qui intègrent ces composants dans des offres commerciales. Pourtant, chacune peut espérer que les autres financeront leur entretien. Ce problème de passager clandestin explique pourquoi une bibliothèque largement utilisée peut rester pauvre. Le nombre de téléchargements mesure une diffusion, pas les ressources réellement disponibles pour sécuriser le projet.
Des mécanismes existaient déjà avant l’affaire XZ : fondations, contrats de support, GitHub Sponsors, programmes de l’Open Source Security Foundation ou financements publics, comme ceux du Sovereign Tech Fund allemand. Leur intérêt est de transformer une reconnaissance abstraite en capacité opérationnelle. Leur limite apparaît lorsque les aides restent ponctuelles, administrativement lourdes ou réservées aux projets sachant déjà se rendre visibles.
Une politique crédible devrait combiner trois engagements :
- Financer la durée, avec des budgets pluriannuels couvrant maintenance et réponse aux incidents.
- Répartir les responsabilités, en soutenant plusieurs mainteneurs et des revues indépendantes.
- Payer les travaux ingrats, notamment les tests, la documentation et la sécurisation des publications.
L’argent doit toutefois préserver l’autonomie du projet. Acheter une influence exclusive sur sa gouvernance déplacerait simplement le risque. Pour une entreprise, contribuer utilement peut aussi signifier détacher un ingénieur quelques heures par semaine, fournir une infrastructure de test ou corriger ses propres usages obsolètes, plutôt qu’exiger davantage d’un mainteneur déjà débordé.
La nomenclature logicielle : une carte, pas un bouclier
La SBOM, ou nomenclature logicielle, promet de répondre à une question élémentaire : qu’y a-t-il dans ce produit ? Des formats comme SPDX et CycloneDX permettent de décrire les composants, leurs versions et leurs relations. Lors d’une alerte, un inventaire exploitable peut éviter plusieurs jours de recherches entre équipes, fournisseurs et archives de compilation.
Encore faut-il qu’il décrive le logiciel réellement livré. Un inventaire produit depuis le dépôt source peut manquer des composants ajoutés pendant la construction, ou diverger du conteneur déployé. Les dépendances transitives compliquent encore le tableau. La SBOM doit donc être reliée aux artefacts distribués et actualisée, pas simplement jointe à un dossier commercial.
Face à XZ, elle aurait surtout aidé à localiser les versions suspectes et à organiser leur remplacement. Elle n’aurait pas, à elle seule, détecté la porte dérobée. Savoir qu’un composant est présent ne dit pas s’il est digne de confiance. L’inventaire devient utile lorsqu’il alimente un dispositif de surveillance, d’analyse et de correction.
Vérifier une version, au-delà de sa signature
Autre raccourci dangereux : croire qu’une signature cryptographique garantit un logiciel sain. Elle permet de vérifier qu’un artefact a été signé par une clé donnée et n’a pas été modifié ensuite. Si le signataire est malveillant, ou si sa chaîne de publication est compromise, une version piégée peut être parfaitement signée.
L’affaire XZ a souligné l’importance de comparer le code du dépôt aux archives effectivement publiées. Des constructions reproductibles peuvent aider des acteurs indépendants à vérifier qu’un même ensemble de sources produit le même résultat. Elles ne prouvent cependant pas que les sources sont inoffensives. Les attestations de provenance, notamment dans l’approche SLSA, documentent quant à elles l’origine et le processus de construction.
Ces dispositifs gagnent à être associés à des permissions limitées, des environnements de compilation isolés et une validation croisée des publications sensibles. Aucune mesure ne suffit seule. L’objectif consiste à rendre une manipulation plus difficile, plus visible et moins dépendante de la vigilance exceptionnelle d’une seule personne.
Et maintenant ?
Et maintenant ? À l’horizon de septembre 2026, le progrès le plus utile serait de traiter les dépendances critiques comme une infrastructure à entretenir, plutôt que comme un stock gratuit à consommer. Cela supposerait des acheteurs exigeant des preuves vérifiables, des entreprises finançant leurs composants essentiels et des mainteneurs disposant du temps nécessaire pour refuser une modification suspecte. Le risque serait, à l’inverse, d’empiler les obligations documentaires sans payer le travail qu’elles créent. La sécurité de l’open source ne se décrète pas : elle se construit avec des outils, des contre-pouvoirs et des personnes disponibles.
