La cybersécurité des chaînes logicielles open source fait aujourd’hui partie des préoccupations majeures des RSSI, des DSI… mais aussi des assureurs. L’attaque survenue fin août 2025 autour du package JavaScript nx, publié sur la plateforme npm, illustre à quel point les vecteurs d’exposition évoluent vite, et à quel point une vulnérabilité située en amont peut contaminer un grand nombre d’acteurs en aval.

Ce que révèle cette attaque va bien au-delà d’une simple faille dans un outil open source. Elle remet en question la manière dont les logiciels sont développés et mis à jour aujourd’hui, en particulier à travers les chaînes dites CI/CD, qui automatisent les différentes étapes de développement, de test et de mise en ligne du code. Ces processus, très efficaces, permettent aux équipes techniques de déployer des changements rapidement et fréquemment, mais deviennent aussi des faiblesses si leur sécurité est négligée. L’attaque met également en lumière des sujets critiques comme la gestion des identifiants d’accès, la dépendance à des briques logicielles partagées entre projets et l'inventivité toujours plus poussée des attaquants pour faire sortir discrètement des données sensibles. Un élément particulièrement nouveau dans cette affaire est l’intégration de l’intelligence artificielle directement dans le programme malveillant, pour adapter en temps réel la manière dont les fichiers à exfiltrer sont identifiés.

Tout a commencé par une faille dans un fichier de configuration utilisé pour automatiser certaines tâches sur la plateforme cloud GitHub. 

Vu de haut, GitHub est un site web et un service de cloud qui aide les développeurs à stocker et à gérer leur code, ainsi qu’à suivre et contrôler les modifications qui lui sont apportées. Il est utilisé par 90% des développeurs. 

Un processus automatisé, chargé de vérifier les titres des demandes de modification du code sur GitHub, contenait une erreur classique mais aux conséquences graves : une commande système y était exécutée sans protection suffisante contre les entrées malveillantes. Un attaquant a pu exploiter cette faiblesse pour insérer un script malveillant, qui a ensuite déclenché un second processus, encore plus sensible, utilisé pour publier automatiquement de nouvelles versions du composant nx sur le registre de modules JavaScript npm.

Ces nouvelles versions, officiellement publiées sous le nom de l’équipe de développement, contenaient un script malveillant s’exécutant dès l’installation du package, c'est à dire localement sur les machines des développeurs. 

Une fois lancé, ce script parcourait les fichiers des l’utilisateurs à la recherche de données sensibles : tokens d’authentification, fichiers de configuration, variables d’environnement, voire même des clés SSH ou des fichiers de portefeuilles cryptographiques. Le plus inquiétant est que ces données étaient ensuite exfiltrées non pas vers un serveur tiers, mais directement dans un dépôt GitHub créé à l’insu de l’utilisateur, sur son propre compte, c'est une page web accessible publiquement. Cette page créée par le malware appartenait à la victime. 

Ce mode d’exfiltration, à la fois discret et très difficile à tracer, utilise l’infrastructure GitHub comme canal de fuite : aucune requête vers un domaine inconnu, aucun flux sortant suspect… tout passe par GitHub lui-même. La victime a parfois mis du temps à constater qu'elle possédait une page publique qu'elle n'avait pas créée et qui contenait des informations confidentielles, pouvant être récupérées par les hackers. 

Parallèlement, le programme malveillant comportait un mécanisme inédit. Il était capable de détecter la présence éventuelle, sur l’ordinateur de la victime, d’outils d’intelligence artificielle en ligne de commande, tels que Claude, Gemini ou Amazon Q. Lorsqu’ils étaient disponibles, le logiciel générait automatiquement des instructions formulées en langage naturel pour que ces outils identifient eux-mêmes les fichiers potentiellement sensibles à rechercher. 

On parle ici d’un logiciel malveillant dit “renforcé par l’intelligence artificielle” : l’attaque s’appuie sur la capacité de ces outils à comprendre le contexte et à s’adapter, afin d’améliorer la phase de repérage des données à voler. Même si l’efficacité de cette technique reste limitée — moins d’un quart des tentatives ont permis une collecte réellement exploitable —, son niveau de sophistication marque une étape et une évolution significative dans les méthodes utilisées par les attaquants.

Les conséquences de l’attaque ont été particulièrement importantes. Plus de 1 700 utilisateurs ont été touchés dès la première phase. Par la suite, des milliers de dépôts de code initialement privés ont été rendus publics, volontairement ou non, à travers l’utilisation frauduleuse des identifiants d’accès récupérés. À ce jour, on recense plus de 6 700 comptes piratés et donc ayant exposé des informations sensibles publiquement. 

Le temps de réaction a également soulevé des inquiétudes : d’après les analyses menées par l’équipe de recherche de l’entreprise WIZ, 80 % des identifiants volés étaient encore actifs quarante-huit heures après le début de l’incident. Plusieurs organisations n’ont pris conscience de la compromission que plusieurs jours plus tard, soit en consultant leurs journaux d’activité, soit après avoir été informées par des spécialistes en cybersécurité.

Ce type de situation est particulièrement préoccupant pour les acteurs du secteur assurantiel. Il montre que l’exposition au risque ne provient pas toujours d’une erreur interne ou d’une faille propre à l’entreprise assurée, mais d'un tiers. 

Il suffit qu’un prestataire, un développeur externe, ou même une simple extension installée dans un environnement de travail télécharge une version compromise d’un composant logiciel pour que débute une chaîne de compromissions invisibles. Et comme la fuite d’informations ne déclenche pas nécessairement d’alerte, la compromission peut passer totalement inaperçue… jusqu’à ce que les conséquences apparaissent, parfois bien plus loin dans la chaîne de responsabilité.

En l'espèce, une partie des développeurs qui sont souvent freelance, sont des tiers qui utilisent la plateforme GitHub. Au sein de GitHun ils collaborent avec des informaticiens et autres développeurs salariés de leurs clients. 

Dès lors où se situent les responsabilités. Pour une même vulnérabilité et une même information exfiltrée, les données sensibles sont exposées par le compte GitHub d'un prestataire et à la fois par le compte GitHub d'un développeur salarié. In fine, c'est la plateforme GitHub qui présente une vulnérablité. La question de la garantie mobilisable peut-être discutée...

Pour les porteurs de risque, cette affaire soulève plusieurs questions. Comment évaluer l’exposition réelle d’un assuré à ce type d’attaque ? Comment anticiper les conséquences d’une compromission en supply chain logicielle ? Et surtout, quels critères faut-il intégrer dans une politique de souscription cyber pour couvrir ces nouveaux risques sans basculer dans la sur-exclusion ?

Chez CnC Expertise, nous recommandons d’intégrer dès à présent des indicateurs spécifiques liés à la gouvernance de la sécurité informatique dans les grilles d’évaluation des risques numériques. Cela suppose, par exemple, la mise en place de vérifications régulières des processus automatisés de développement et de mise en production, une gestion rigoureuse des identifiants et des droits d’accès en fonction des niveaux de responsabilité, une analyse approfondie des composants logiciels tiers utilisés, ainsi qu’une capacité à repérer les comportements anormaux, notamment dans les dépôts de code ou les outils utilisés par les équipes de développement. Nous accompagnons déjà plusieurs compagnies d’assurance et cabinets de courtage dans l’intégration concrète de ces bonnes pratiques au sein de leurs audits techniques.

L’affaire Nx n’est pas un cas isolé. Elle s’inscrit dans une tendance de fond où la chaîne d’approvisionnement numérique devient l’un des principaux vecteurs d’attaque. L’open source est une richesse pour l’innovation, mais aussi une surface d’attaque massive et parfois mal maîtrisée. 

Dans ce contexte, il est essentiel que les acteurs de l’assurance et de la cybersécurité avancent main dans la main, avec des référentiels communs et une capacité partagée d’anticipation.

Ce type d’incident montre une chose : la confiance, en cybersécurité, ne se décrète pas. Elle se construit, fichier par fichier, pipeline par pipeline. Et elle se protège.