Cher lecteur,

Cette semaine a été étrange. Au cours des derniers mois, nous avons assisté à une série d'attaques significatives de la chaîne d'approvisionnement. La communauté tire la sonnette d'alarme depuis un certain temps, et la vérité est que nous marchons sur des œufs. Il semble inévitable que quelque chose de plus grand, de pire, se prépare.

Dans ce billet, je souhaite partager quelques-uns des principaux enseignements de cette semaine. J'ai eu l'occasion de m'entretenir avec Josh Junon, mieux connu sous le nom de Qix, et de l'interviewer sur son expérience au cœur de cette épreuve. Josh est le mainteneur qui a été compromis lors de l'attaque de phishing, et il est également à l'origine de certains des packages les plus largement utilisés dans l'écosystème npm.

Avant de plonger dans cette conversation (Voir l'interview ci-dessous), jetons un rapide coup d'œil aux événements qui nous ont menés ici.

Prologue - Impact

Lundi, lorsque j'ai vu pour la première fois les alertes dans notre tableau de bord interne Aikido Intel, il était immédiatement clair que cela pouvait être l'un de ces scénarios du pire qui m'empêchent de dormir. Des packages majeurs comme debug, chalk, et seize autres avaient été compromis par des logiciels malveillants. Les retombées potentielles étaient tout simplement catastrophiques.

Les chiffres parlent d'eux-mêmes :

• Collectivement, les packages compromis sont téléchargés environ 2,6 milliards de fois chaque semaine.
• JFrog estime que les versions malveillantes seules ont été téléchargées environ 2,6 millions de fois.
• Wiz a rapporté que 99 % de leurs environnements cloud dépendent d'au moins un de ces packages, et dans 10 % des cas, le code malveillant était présent.

À tous égards, nous avons frôlé la catastrophe. Comme beaucoup l'ont noté depuis, nous avons échappé de peu à une catastrophe. La seule raison pour laquelle les dégâts n'ont pas été bien pires tient à deux facteurs :

• Les attaquants étaient concentrés sur le vol de cryptomonnaies.
• Ils ont fait de grands efforts pour rester indétectés.

Mais l'histoire nous rappelle à quel point cette chance peut être fragile. Il suffit de remonter au 26 août 2025 pour voir ce qui se passe lorsqu'un attaquant est moins prudent dans son exécution.

Prologue - Compromission de Nx

Le 26 août, le gestionnaire de paquets Nx a été compromis, mais les attaquants ont opté pour un modus operandi très différent :

• Ils ont exfiltré des secrets et des jetons des machines de développeurs et les ont divulgués publiquement sur GitHub.
• Ils ont ensuite utilisé ces jetons pour s'introduire dans des comptes GitHub, rendant ainsi des dépôts privés accessibles au public.

Ce fut un vol éclair classique. Un rappel brutal que la compromission d'un paquet largement utilisé ne se limite pas à créer des désagréments. Elle peut causer des dommages réels et durables. À bien des égards, ce fut un coup de semonce, montrant à quel point nous sommes exposés.

La conversation avec Josh

Après avoir contacté Josh pour l'alerter de la compromission et poursuivi nos échanges par la suite, ma collègue Mackenzie et moi avons réalisé qu'il serait fascinant de nous entretenir avec lui pour recueillir son témoignage direct sur cette expérience. Heureusement, Josh s'est montré ouvert à cette idée. 

S'en est suivie une conversation réfléchie et franche qui m'a vraiment marqué. J'aimerais partager ici quelques-uns de mes principaux points clés. Si vous souhaitez le contexte complet, vous pouvez regarder l'intégralité de la discussion de 45 minutes ici :

Enseignement : La confiance par la vulnérabilité

La sécurité consiste généralement à éliminer la vulnérabilité. Mais dans l'open source, la confiance n'est possible que grâce à la vulnérabilité. Les mainteneurs mettent leur code, et une partie d'eux-mêmes, à la disposition du monde, l'exposant à des milliards de téléchargements et d'innombrables utilisateurs. Cette exposition exige un acte de foi.

Lorsque Josh a parlé ouvertement de la façon dont il a été victime de phishing, il a montré le genre de vulnérabilité qui renforce réellement la confiance. En admettant ses erreurs, en étant transparent et en restant engagé auprès de la communauté, il nous a rappelé que l'open source n'est pas géré par des entreprises anonymes, mais par des personnes. Et la confiance en ces personnes est ce qui fait fonctionner l'ensemble du système.

Au final, le paradoxe est que la sécurité cherche à éliminer la vulnérabilité, mais la confiance dans l'open source est bâtie sur elle.

Je pense que ce qui a fait une énorme différence, c'est le type de réponse générale. Je sais qu'il a été souligné à plusieurs reprises que la transparence a été appréciée. Et je pense que je le savais déjà. J'ai eu quelques cas dans l'open source où j'ai moi-même fait des erreurs, pas en matière de sécurité, mais en étant simplement transparent et honnête – et cela a immédiatement épargné beaucoup de maux de tête, de temps et d'argent à de nombreuses personnes. Et c'est toujours apprécié.

Enseignement : Tomber dans l'open source

Josh n'a jamais eu l'intention de devenir un pilier de l'écosystème JavaScript. Il a commencé à coder adolescent, en expérimentant avec PHP, C# et JavaScript, et l'open source n'était qu'un endroit pour partager les projets qui l'intéressaient. Il était attiré par des choses comme l'ajout de couleurs aux terminaux ou la création de petits utilitaires, sans jamais imaginer qu'ils finiraient au cœur des logiciels modernes.

Avec le temps, ses contributions ont mené à de plus grandes responsabilités. Pour certaines bibliothèques, comme chalk, il a été invité à rejoindre l'équipe en tant que mainteneur après avoir contribué à des correctifs. Pour d'autres, comme debug, il a hérité de la gestion des précédents mainteneurs. Ce qui avait commencé comme un passe-temps s'est progressivement transformé en la maintenance de certains des paquets les plus largement utilisés de l'écosystème.

Des années plus tard, Josh s'est retrouvé responsable de milliards de téléchargements hebdomadaires. Ce qui n'était autrefois que de petits projets secondaires était devenu une infrastructure internet critique. Non pas grâce à une planification minutieuse ou à une ambition démesurée, mais simplement en étant au bon endroit au bon moment, et en disant « oui » lorsqu'on lui a demandé de l'aide.

Ils ont commencé à être utilisés dans de plus en plus d'endroits, probablement même là où ils n'auraient jamais dû l'être. Honnêtement, quelques-uns de ces paquets ne devraient même pas exister, et je serai le premier à l'admettre. Puis un jour, vous vous réveillez et réalisez qu'un petit utilitaire que vous avez écrit pour manipuler des valeurs de tableau est utilisé par 55 000 personnes et téléchargé 300 millions de fois par semaine. Vous n'avez jamais demandé cette responsabilité.

Enseignement : L'impuissance face à la perte de contrôle

La partie la plus difficile de l'incident pour Josh n'a pas été de réaliser qu'il avait été victime de phishing. Ce fut l'impuissance qui a suivi. Une fois que les attaquants ont eu son mot de passe et son code 2FA, ils étaient essentiellement lui aux yeux de npm. Ils ont réinitialisé ses jetons 2FA, modifié les détails d'authentification et l'ont bloqué hors de son propre compte. Même des actions de base comme la réinitialisation de son mot de passe ou la récupération de l'accès ne fonctionnaient pas.

Pendant près de 12 heures, tout ce que Josh a pu faire a été d'observer de l'extérieur la propagation de versions malveillantes de ses paquets sur internet. Il n'avait aucun moyen d'intervenir directement, aucun bouton sur lequel appuyer, aucun canal rapide vers le support de npm. Au lieu de cela, il a été contraint de s'appuyer sur les forums d'aide publics et d'attendre. 

Le sentiment d'impuissance est ce qui l'a marqué. Comme il l'a dit, il n'y avait aucune transparence, aucun outil permettant à un mainteneur en crise de reprendre le contrôle. Au milieu de l'une des plus grandes compromissions de la chaîne d'approvisionnement de mémoire récente, la personne la plus fiable pour ces paquets a été laissée sur la touche.

Le bouton de réinitialisation du mot de passe ne fonctionnait pas. Je n'ai reçu aucun e-mail pendant tout cet événement. La réinitialisation du mot de passe n'a rien donné. Donc, même si l'e-mail était toujours le même sur le compte, ce que je crois encore, la réinitialisation du mot de passe ne fonctionnait pas… Il n'y avait aucun recours autre que de contacter npm via leur formulaire d'aide public non authentifié.

Enseignement : Une balle évitée

Le malware implanté dans chalk, debug et les autres packages compromis était sérieux, mais sa portée était étrangement limitée. Il a tenté de voler des cryptomonnaies en s'injectant dans les contextes de navigateur. Cette décision des attaquants, qu'elle soit due à la cupidité ou à un manque de vision, est la seule raison pour laquelle les conséquences n'ont pas été bien pires.

Comme l'a dit Josh, cela aurait pu être catastrophique. Ces packages s'exécutent partout : ordinateurs portables, serveurs d'entreprise, pipelines CI/CD et environnements cloud. Ils auraient pu exfiltrer des clés AWS, divulguer des secrets ou chiffrer des fichiers pour rançon. Au lieu de cela, les attaquants se sont limités à un objectif restreint.

Il aurait pu faire n'importe quoi et il était exécuté… sur des machines d'entreprise, des machines personnelles, dans de petites entreprises, des pipelines CI/CD. Et le fait qu'il n'ait rien fait [de pire] est la balle que nous avons évitée.

La leçon n'est pas que le système a fonctionné. C'est que la chance était de notre côté cette fois-ci. Considérer cela comme un « non-événement » passe à côté de l'essentiel. Le prochain attaquant pourrait ne pas être aussi mesuré.

Analyse : Le coût humain de l'open source

Derrière chaque package largement utilisé se trouve un être humain, souvent travaillant discrètement et sans tambour ni trompette. Pour Josh, la partie la plus difficile n'était pas seulement le compromis technique. C'était le tribut émotionnel qui a suivi. Il a décrit le premier jour comme étant en mode pilote automatique, s'efforçant de contenir les dégâts. Ce n'est qu'après que le poids l'a frappé : l'embarras, l'anxiété et la pensée troublante que son erreur aurait pu blesser des gens.

C'était un lundi. Une fois que j'ai récupéré mon compte cet après-midi-là ou ce soir-là, c'était comme, ok, je peux éteindre l'interrupteur et maintenant je peux juste m'allonger dans mon lit, fixer le plafond et penser à ce qui venait de se passer… Le lendemain n'était que de l'embarras. Je ne voulais pas montrer mon visage. Je ne voulais pas sortir.

C'est la réalité cachée de l'open source. De petits projets créés « pour le plaisir » deviennent des infrastructures critiques, totalisant des milliards de téléchargements. Les mainteneurs n'ont jamais demandé cette responsabilité, pourtant ils en supportent le stress lorsque les choses tournent mal. La communauté voit le code, mais néglige souvent le coût humain de sa maintenance.

L'expérience de Josh nous rappelle que la sécurité de l'écosystème ne se limite pas à une MFA plus robuste ou à une réponse aux incidents plus rapide. Il s'agit aussi de soutenir les mainteneurs qui assument cette responsabilité — en respectant leurs limites, en faisant preuve d'empathie et en reconnaissant que la confiance repose sur les personnes derrière le code.

Appel à l'action

Cet incident a mis en lumière la façon dont une seule compromission peut se propager à travers la chaîne d'approvisionnement logicielle. Ce n'était pas catastrophique cette fois-ci, mais cela aurait pu l'être facilement. La leçon n'est pas de paniquer, mais d'agir.

• Pour les registres (npm, PyPI, etc.) : Appliquez une MFA résistante au phishing pour les mainteneurs à fort impact et fournissez des canaux de réponse clairs et rapides lorsque des comptes sont compromis.
• Pour les organisations : Améliorez l'hygiène des dépendances. Épinglez les versions, surveillez les altérations et intégrez les contrôles de sécurité de la chaîne d'approvisionnement dans les pipelines CI/CD.
  Pour les mainteneurs : Utilisez des clés matérielles, évitez les décisions de sécurité hâtives prises sous le stress, et misez sur la transparence en cas de problème.
• Pour la communauté : Soutenez les humains derrière l'open source. Respectez leurs limites, fournissez des ressources si possible, et réagissez avec empathie lorsque des erreurs se produisent.

Le véritable appel à l'action est simple : traitez la sécurité de l'écosystème comme une responsabilité partagée. Les plateformes, les entreprises et les communautés ont toutes un rôle à jouer pour s'assurer que le prochain incident ne dégénère pas en quelque chose de pire.

Épilogue

Ce fut une semaine surréaliste, d'être au cœur d'une tempête qui a attiré tant de presse et d'attention, et pour de bonnes raisons. Observer les événements se dérouler en temps réel, des premières alertes dans notre tableau de bord au flot de rapports publics, a donné l'impression d'être sur une faille alors que le sol se dérobait sous nos pieds. C'est un rappel de la fragilité de notre écosystème.

Ce qui s'est déroulé s'est dangereusement rapproché du pire scénario que je passe mes journées à craindre en matière de sécurité open source. Mais ce que je crains le plus, ce n'est pas l'e-mail de phishing, le malware, ni même les gros titres. C'est que nous laissions passer ce moment sans changement.

Si l'industrie hausse les épaules, traite cela comme un incident de plus et reprend ses activités comme d'habitude, nous n'aurons rien appris. Et la prochaine fois, car il y aura une prochaine fois, nous n'aurons peut-être pas autant de chance. La première fois, honte aux attaquants. La deuxième fois, honte à nous.

Et si nous ne prenons pas de mesures pour en tirer des leçons, l'érosion silencieuse de la confiance dans l'open source pourrait s'avérer être la conséquence la plus dommageable de toutes.

‍