En 2024, Internet est probablement passé à deux doigts d’une catastrophe majeure. Pas à cause d’un ransomware, ni d'une fuite de données massive et ni d’un nouveau groupe de hackers ultra sophistiqué.

Le danger venait d’un composant open source quasiment inconnu du grand public mais énormément utilisé : XZ Utils.

Ce qui m’amène à vous parler des attaques par supply chain.

Une attaque par supply chain est une attaque qui ne cible pas directement la victime finale, mais qui passe par un intermédiaire : un fournisseur, un logiciel, une mise à jour, une bibliothèque open source ou encore un prestataire technique. L’objectif est simple : compromettre un élément déjà utilisé et considéré comme fiable afin de toucher indirectement tous ceux qui lui font confiance.

Plutôt que de forcer l’entrée d’une entreprise bien protégée, les attaquants vont donc s’attaquer à un maillon de son système d’information. Et c’est précisément ce qui rend ces attaques particulièrement efficaces. Un logiciel signé inspire confiance. Une mise à jour officielle paraît légitime. Un fournisseur déjà intégré au système bénéficie souvent d’autorisations étendues. Dans ce contexte, les mécanismes de sécurité traditionnels sont plus souples et deviennent beaucoup moins efficaces puisque les activités malveillantes ressemblent, en apparence, à des comportements normaux.

C’est d’ailleurs ce qui rend les attaques supply chain aussi inquiétantes aujourd’hui. Les entreprises modernes dépendent d’une quantité immense de composants externes : solutions SaaS, services cloud, bibliothèques open source, outils d’administration, dépendances logicielles, prestataires… Chaque couche supplémentaire apporte de nouvelles fonctionnalités, mais ajoute également un nouveau point de confiance potentiellement exploitable.

L’un des exemples récent et connu est l’affaire SolarWinds en 2020. Des attaquants avaient réussi à compromettre le processus de mise à jour d’Orion, un logiciel de supervision utilisé dans le monde entier. Une backdoor a ensuite été distribuée directement via une mise à jour officielle de l’éditeur. Résultat : des milliers d’organisations ont installé elles-mêmes le logiciel compromis, y compris des agences gouvernementales américaines et de grandes entreprises stratégiques. Cette affaire a fait grand bruit et marqué un tournant dans la cybersécurité moderne, car elle a montré qu’une simple relation de confiance pouvait servir de surface d’attaque pour une diffusion massive.

Mais l’affaire XZ Utils est probablement encore plus fascinante et plus inquiétante.

Parce qu’ici, il ne s’agit pas simplement d’un système compromis ou d’une mise à jour malveillante. L’attaque semble avoir été construite sur plusieurs années, avec une approche presque invisible. En novembre 2021, un développeur utilisant le pseudonyme “Jia Tan” a commencé progressivement à participer au projet open source. Au départ, rien d’anormal : contributions techniques, corrections de bugs, participation active à la maintenance, échanges avec la communauté… Petit à petit, il gagne la confiance du projet et devient un contributeur important.

Et c’est là que cette histoire devient particulièrement intéressante, parce qu’elle met en lumière un problème bien plus large que la simple cybersécurité technique. Une immense partie de l’infrastructure numérique mondiale repose aujourd’hui sur des projets open source maintenus par très peu de personnes, parfois même une seule. Des composants critiques utilisés partout peuvent dépendre de développeurs isolés, souvent sous pression, peu financés et confrontés à une charge de travail énorme. Dans le cas de XZ Utils, le mainteneur historique semblait justement fatigué et relativement isolé, ce qui aurait facilité cette prise de confiance progressive.

Une fois suffisamment intégré au projet, du code malveillant extrêmement sophistiqué commence à être introduit dans XZ Utils. La premiere version (5.6.0) où l'on trouve du code malveillant est publiée en Février 2024. La backdoor était discrète, obfusquée et pensée pour rester pratiquement invisible. L’objectif était de compromettre OpenSSH afin de permettre un accès distant à des systèmes Linux critiques. Le plus impressionnant dans cette affaire reste probablement le niveau de sophistication de l’attaque : le code malveillant était caché dans le processus de compilation lui-même, ce qui rendait sa détection particulièrement complexe.

Et pourtant, cette attaque a été découverte presque par hasard. Des anomalies de performance inhabituelles lors de benchmarks ont attiré l’attention de l’ingénieur Microsoft Andres Freund en mars 2024, qui a commencé à enquêter. En creusant davantage, il a découvert progressivement la présence du code malveillant avant que celui-ci ne soit déployé massivement dans des environnements de production. Le lendemain de sa découverte il la partage et la faille obtient le numéro CVE-2024-3094 avec un score de sévérité de 10.0. Le développeur "Jia Tan" a, par la suite, complètement disparu. Il existe des théories selon lesquelles un état serait derriere cette tentative mais aucune enquête n'a pu aboutir.

Cette affaire a provoqué un véritable choc dans l’industrie, car elle montre que les attaques supply chain modernes ne reposent plus uniquement sur l’exploitation de failles techniques. Elles exploitent désormais la complexité des écosystèmes numériques, les dépendances invisibles entre logiciels, mais aussi les faiblesses humaines : fatigue, isolement, manque de ressources ou confiance accordée aux contributeurs.

Aujourd’hui, aucune entreprise ne maîtrise réellement l’ensemble de sa chaîne logicielle. Entre les dépendances open source, les services tiers, les fournisseurs cloud et les outils externes intégrés quotidiennement aux systèmes d’information, la surface d’attaque est devenue gigantesque. Et plus cette dépendance grandit, plus les attaques supply chain deviennent stratégiques pour les cybercriminels et les groupes étatiques.

C’est précisément pour cette raison que les entreprises doivent désormais aller beaucoup plus loin dans leur approche de la cybersécurité. Cartographier leurs dépendances, surveiller les accès tiers, contrôler les mises à jour critiques, appliquer des principes Zero Trust ou encore renforcer la visibilité sur leur supply chain logicielle devient indispensable.