Attaques de la chaîne d’approvisionnement et la crise de sécurité de l’open source

Introduction

En mars 2024, un ingénieur de Microsoft nommé Andres Freund enquêtait sur une utilisation inexpliquée du processeur sur un serveur Debian Linux lorsqu’il est tombé sur l’une des attaques de chaîne d’approvisionnement logicielle les plus sophistiquées jamais découvertes. Un contributeur malveillant qui avait passé deux ans à bâtir la confiance au sein du projet open source XZ Utils — une bibliothèque de compression utilisée par pratiquement toutes les distributions Linux — avait introduit un code de porte dérobée soigneusement dissimulé qui aurait donné un accès distant non autorisé à tout système exécutant les versions compromises.

Le code était si bien caché, et l’attaque si patiente et sophistiquée, que les chercheurs en sécurité l’ont qualifiée de quasi-catastrophe pour l’infrastructure d’Internet à une échelle comparable à Heartbleed. Seule une combinaison improbable d’un ingénieur observateur et de caractéristiques de performance légèrement anormales a empêché la porte dérobée d’être intégrée dans les distributions stables.

L’incident XZ Utils n’était pas isolé. Il constituait l’exemple le plus frappant d’une tendance qui a transformé la manière dont la communauté de la sécurité envisage la confiance logicielle : les attaques de chaîne d’approvisionnement — compromettre le pipeline de développement et de distribution des logiciels plutôt que d’attaquer directement les utilisateurs finaux — représentent la catégorie de menaces cybersécuritaires la plus lourde de conséquences et la plus rapidement croissante.

Qu’est-ce qu’une attaque de la chaîne d’approvisionnement ?

Une attaque de la chaîne d’approvisionnement logicielle compromet le pipeline par lequel le logiciel parvient aux utilisateurs finaux — plutôt que d’attaquer les utilisateurs directement. La cible peut être :

• Les dépôts de code source (corruption du code avant sa compilation)
• Les systèmes de build (compromission des serveurs qui compilent le code)
• Les registres de paquets (publication de paquets malveillants imitant des paquets légitimes)
• Les mises à jour logicielles (compromission du mécanisme de mise à jour pour diffuser du code malveillant)
• Les mainteneurs open source (compromission des individus qui maintiennent des bibliothèques largement utilisées)
• Les fournisseurs tiers (compromission d’un prestataire disposant d’un accès de confiance chez ses clients)

La puissance des attaques de chaîne d’approvisionnement repose sur la confiance. Lorsqu’une mise à jour d’un fournisseur de confiance constitue le vecteur d’attaque, les contrôles de sécurité traditionnels — pare-feu périmétrique, protection des terminaux, filtrage des e-mails — n’offrent aucune protection. Le code malveillant arrive avec une signature valide d’une source de confiance, via un mécanisme de mise à jour approuvé, et s’installe avec l’autorisation explicite de l’utilisateur.

SolarWinds : l’attaque qui a tout changé

L’attaque SolarWinds de décembre 2020 a établi le modèle de compromission sophistiquée de la chaîne d’approvisionnement à l’échelle mondiale.

SolarWinds produit un logiciel de surveillance réseau (Orion) utilisé par environ 18 000 organisations dans le monde, y compris la plupart des agences fédérales américaines, des sous-traitants de la défense et des grandes entreprises. Des hackers parrainés par l’État russe (attribués au groupe Cozy Bear du SVR) ont compromis le pipeline de build de SolarWinds — les systèmes qui compilent le code source d’Orion en logiciel déployable — et ont injecté du code malveillant (baptisé SUNBURST) qui était compilé dans les mises à jour légitimes d’Orion.

Pendant environ neuf mois, chaque organisation ayant installé une mise à jour légitime et numériquement signée d’Orion installait également une porte dérobée. Le malware était conçu pour être extraordinairement furtif : il attendait deux semaines après l’installation avant de s’activer, déguisait ses communications en trafic Orion légitime, et ne s’activait que dans des environnements semblant être de véritables déploiements d’entreprise (et non des bacs à sable de chercheurs en sécurité).

Au moins 100 organisations majeures et neuf agences fédérales américaines ont été compromises de manière confirmée, notamment le Département du Trésor, le Département d’État, le Département de la Sécurité intérieure et certaines composantes du Pentagone. L’étendue complète du renseignement collecté grâce à cet accès reste classifiée.

SolarWinds a démontré que même des organisations sophistiquées disposant d’équipes de sécurité solides — parmi les cibles figuraient les sociétés de cybersécurité Malwarebytes et Mimecast — pouvaient être intégralement compromises par l’intermédiaire d’un fournisseur de confiance.

La quasi-catastrophe XZ Utils : la confiance open source comme surface d’attaque

L’incident XZ Utils de 2024 a révélé un vecteur d’attaque différent : l’ingénierie sociale des mainteneurs de logiciels open source.

L’attaquant opérait sous le pseudonyme « Jia Tan » et a passé environ deux ans à contribuer au projet XZ Utils — soumettant des améliorations de code légitimes et utiles, bâtissant une réputation de contributeur fiable, et assumant progressivement les responsabilités de co-mainteneur auprès du mainteneur originel (apparemment stressé et surchargé de travail) du projet.

Au cours de cette période, l’attaquant s’est également livré à ce qui semblait être une pression sociale coordonnée : création de faux comptes secondaires se plaignant du manque de publications et de la réactivité du mainteneur, ajoutant une urgence apparente aux demandes de fusion de code. Le mainteneur originel a fini par accorder à Jia Tan des droits étendus sur le projet.

Le code malveillant a ensuite été introduit via une chaîne complexe de commits rendant la porte dérobée extraordinairement difficile à détecter — la dissimulant dans des fichiers de données de test binaires, utilisant des manipulations du système de build, et employant des techniques d’obfuscation nécessitant une analyse technique approfondie pour être identifiées.

La porte dérobée ciblait l’authentification SSH sur les systèmes utilisant systemd — le système d’initialisation utilisé par la plupart des grandes distributions Linux. Si elle avait été déployée dans les versions stables, elle aurait donné à des parties non autorisées la capacité de s’authentifier sur tout serveur Linux affecté au moyen d’une clé cryptographique spécifique. L’ampleur de l’impact potentiel — essentiellement chaque serveur Linux connecté à Internet — était vertigineuse.

Pourquoi l’open source est à la fois le problème et la solution

Les logiciels open source font tourner Internet. Le noyau Linux équipe chaque téléphone Android, la plupart des serveurs web, l’essentiel de l’infrastructure cloud. La bibliothèque OpenSSL sécurise les connexions HTTPS à l’échelle mondiale. Log4j (une bibliothèque de journalisation Java) était intégrée dans des milliers d’applications utilisées par pratiquement toutes les grandes organisations. npm, PyPI et Maven hébergent des millions de paquets qui constituent le socle du développement logiciel moderne.

Le paradoxe sécuritaire est que la force du logiciel open source — un code transparent, révisé par la communauté — est aussi sa vulnérabilité. La transparence signifie que quiconque peut lire le code et y trouver des failles ; mais le code révisé par la communauté est souvent maintenu par des bénévoles travaillant sur leur temps libre, sans les ressources nécessaires à un audit de sécurité exhaustif, et vulnérables au type d’ingénierie sociale qui a compromis XZ Utils.

Principales vulnérabilités structurelles :

Le « problème left-pad » : Un seul développeur maintenant un paquet largement utilisé peut devenir un point de défaillance unique pour l’ensemble de l’écosystème. Lorsque le paquet left-pad a été retiré de npm en 2016, des milliers de builds logiciels ont échoué à travers le monde — non pas à cause d’une faille de sécurité, mais simplement parce qu’une seule personne a pris une seule décision.

L’épuisement des mainteneurs : Une part significative de l’infrastructure open source est maintenue par des individus surchargés, sous-payés (quand ils le sont), et soumis à la pression sociale de communautés d’utilisateurs exigeantes. Cela crée des conditions dans lesquelles les mainteneurs prennent de mauvaises décisions en matière de sécurité, deviennent vulnérables à l’ingénierie sociale (comme dans le cas de XZ Utils) ou sont tentés d’introduire eux-mêmes du code malveillant.

Les chaînes de dépendances : Les applications logicielles modernes utilisent des centaines, voire des milliers de bibliothèques tierces, chacune avec ses propres dépendances. Une vulnérabilité ou une compromission dans n’importe quelle bibliothèque, à n’importe quel niveau de la chaîne de dépendances, se propage à toute application qui en dépend directement ou transitivement.

L’héritage de confiance : Le code accepté dans un registre de paquets réputé ou un projet open source hérite de la confiance de cette plateforme. Un paquet npm malveillant imitant un paquet légitime populaire (typosquatting) peut être installé par des développeurs qui font des fautes de frappe dans leurs instructions d’importation.

Confusion de dépendances et typosquatting : l’attaque permanente

Alors que SolarWinds et XZ Utils représentent des attaques sophistiquées et patientes, les attaques de chaîne d’approvisionnement à haut volume exploitent des mécanismes plus simples :

Confusion de dépendances (dependency confusion) : De nombreuses organisations maintiennent des registres de paquets internes privés pour leurs composants logiciels propriétaires. Les attaquants qui découvrent les noms de paquets privés peuvent publier des paquets malveillants portant les mêmes noms sur des registres publics. Si les environnements de développement sont configurés pour interroger les registres publics avant les registres privés, le paquet public malveillant est installé à la place du paquet privé légitime. Le chercheur en sécurité Alex Birsan a démontré cette attaque contre Apple, Microsoft et PayPal en 2021 — les trois ont installé ses paquets de preuve de concept.

Typosquatting : Publication de paquets malveillants portant des noms très similaires à des paquets légitimes populaires. « reqeusts » au lieu de « requests » (Python), « lodahs » au lieu de « lodash » (JavaScript). Avec des millions de paquets disponibles, les développeurs qui font des fautes de frappe dans leurs instructions d’importation installent du code malveillant.

Mises à jour malveillantes de paquets : Des paquets légitimes vendus ou transférés à des acteurs malveillants qui diffusent ensuite des mises à jour malveillantes. Plusieurs incidents se sont produits où des paquets populaires ont changé de mains et les mises à jour subséquentes contenaient du code de vol de données.

La réponse réglementaire : SBOMs et exigences de sécurité logicielle

Les réponses gouvernementales et industrielles à la menace des attaques de chaîne d’approvisionnement ont convergé vers plusieurs approches réglementaires et normatives :

Nomenclature logicielle (SBOM — Software Bill of Materials) : Un SBOM est un inventaire formel et lisible par machine de tous les composants — bibliothèques open source, composants commerciaux et leurs dépendances — qui constituent un logiciel. Le décret exécutif américain sur l’amélioration de la cybersécurité (mai 2021) a rendu les SBOMs obligatoires pour tout logiciel vendu au gouvernement fédéral. La logique : on ne peut pas gérer le risque de chaîne d’approvisionnement pour des composants dont on ignore l’existence.

L’adoption des SBOMs a progressé rapidement dans les marchés publics américains et se propage aux secteurs réglementés. Le Cyber Resilience Act de l’UE, adopté en 2024, inclut des exigences SBOM pour les produits contenant des éléments numériques commercialisés sur le marché européen.

Cadres de développement logiciel sécurisé : Le Secure Software Development Framework (SSDF, SP 800-218) du NIST et les recommandations de la CISA sur la sécurité de la chaîne d’approvisionnement logicielle fournissent des pratiques pour sécuriser le pipeline de développement : authentification multifacteur pour les dépôts de code, signature de code, revue des dépendances, isolation de l’environnement de build et analyse de composition logicielle (SCA).

Sigstore : Un projet de la Linux Foundation fournissant une infrastructure gratuite de signature de code et de transparence — facilitant pour les mainteneurs open source la signature cryptographique de leurs publications et permettant aux utilisateurs de vérifier que les paquets installés correspondent à ce qui a été publié. Sigstore a été adopté par PyPI (Python) et est en cours d’adoption par npm (JavaScript) et d’autres registres.

Ce que les organisations doivent faire

Analyse de composition logicielle (SCA — Software Composition Analysis) : Déployer des outils SCA (Snyk, Mend, FOSSA, Black Duck) qui analysent en continu votre base de code et ses dépendances à la recherche de vulnérabilités connues et de problèmes de licence. L’analyse SCA doit être intégrée aux pipelines CI/CD (intégration et déploiement continus) pour détecter les composants vulnérables avant qu’ils n’atteignent la production.

Générer et maintenir des SBOMs : Mettre en œuvre la génération de SBOMs pour tout logiciel que vous produisez. Maintenir des SBOMs pour les logiciels que vous consommez (auprès de vos fournisseurs). Lorsqu’une nouvelle vulnérabilité est découverte dans un composant (comme Log4Shell en 2021), les organisations disposant de SBOMs complets peuvent immédiatement identifier lesquelles de leurs applications sont affectées ; celles qui n’en ont pas font face à des semaines d’investigation manuelle.

Évaluer votre chaîne d’approvisionnement : Pour les logiciels tiers critiques, évaluez les pratiques de sécurité du fournisseur. Signe-t-il ses publications ? Publie-t-il des SBOMs ? Dispose-t-il de procédures de réponse aux incidents de sécurité ? L’attaque SolarWinds aurait pu être détectée plus tôt si les organisations avaient eu davantage de visibilité sur la manière dont SolarWinds gérait son pipeline de build.

Verrouillage et revue des dépendances : Verrouiller les dépendances sur des versions spécifiques dont la fiabilité est connue plutôt que d’accepter automatiquement la dernière version. Examiner les modifications de dépendances proposées (revues de pull requests pour les mises à jour de dépendances) avec autant de rigueur que la revue de votre propre code.

Contrôle des registres privés : Héberger un miroir interne des registres de paquets, en sélectionnant soigneusement les paquets disponibles, plutôt que de permettre aux développeurs d’installer n’importe quel paquet depuis les registres publics.

Conclusion

La sécurité de la chaîne d’approvisionnement logicielle est le défi sécuritaire déterminant pour une industrie dont la production entière — les logiciels qui font fonctionner les banques, les hôpitaux, les gouvernements et chaque appareil connecté — dépend d’une chaîne de confiance complexe et mondialement distribuée. Lorsque cette chaîne est compromise, les conséquences se propagent en cascade à chaque système dépendant.

La quasi-catastrophe XZ Utils a été un avertissement. L’attaque SolarWinds a été une démonstration. L’écosystème open source qui fait tourner Internet est à la fois extraordinairement résilient et structurellement vulnérable. Intégrer la sécurité dans la chaîne d’approvisionnement — par les SBOMs, les publications signées, les pratiques de développement sécurisé et l’investissement soutenu dans la sécurité open source — n’est pas optionnel pour les organisations sérieuses dans la gestion de leur cyber-risque.