La plupart des articles consacrés à la sécurité dans cette newsletter parlent de choses qui vous arrivent directement : un SMS d’hameçonnage, un mot de passe divulgué, un faux site marchand. Celui-ci est différent. Les incidents ci-dessous sont arrivés à des développeurs — les personnes qui écrivent les applications et les services que vous utilisez chaque jour. Mais la raison pour laquelle ils ont leur place ici est simple : si quelqu’un empoisonne les outils utilisés pour créer des logiciels, le poison ne reste pas chez le créateur. Il est livré avec le produit.

Deux événements récents l’illustrent. Aucun n’a fait la une comme le ferait une importante fuite de données, parce qu’aucun des deux ne constitue précisément une fuite vous concernant. Ce sont tous deux des attaques contre la chaîne qui produit les logiciels que vous finissez par installer, ouvrir ou auxquels vous vous connectez.

Des extensions contrefaites déguisées en marques de confiance

Open VSX est une marketplace publique d’extensions pour éditeurs de code — les petits modules complémentaires que les développeurs installent pour bénéficier de la complétion automatique, de l’analyse du code et d’intégrations avec les outils qu’ils utilisent quotidiennement (Visual Studio Code et plusieurs de ses équivalents open source y puisent leurs extensions). Entre le 26 juillet et le 1er août 2026, des chercheurs en sécurité de Manifold Security ont trouvé 77 extensions contrefaites dans le registre. Chacune copiait le nom et l’espace de noms d’une extension réelle et reconnue, mais était publiée depuis un compte qui ne détenait pas l’original — une usurpation classique, parfois appelée squattage d’espace de noms.

Les noms usurpés n’étaient pas choisis au hasard. Ils empruntaient l’identité d’AMD, de LEGO Education, d’Hyperledger, d’Azure, d’Artsy, de projets open source de Salesforce, d’une agence fédérale américaine et — avec une certaine ironie noire — de la marketplace d’extensions elle-même. Les 77 paquets communiquaient tous avec un seul domaine, enregistré seulement 11 jours avant l’apparition du premier faux paquet, un schéma qui évoque une campagne coordonnée et conçue à dessein plutôt qu’une copie opportuniste.

La plupart des fausses extensions faisaient quelque chose de limité : elles signalaient discrètement un nom d’hôte au serveur de l’attaquant, ce qui pouvait n’être, en soi, qu’une vérification destinée à savoir qui avait installé l’appât. Mais les chercheurs ont constaté qu’environ un quart des 77 — 19 paquets — allaient plus loin. Quelques secondes après leur activation, ils recueillaient le nom d’hôte, le nom d’utilisateur du système d’exploitation, les informations sur l’éditeur et un identifiant de machine. Ils lisaient ensuite le projet ouvert par le développeur : le dépôt distant git (qui révèle l’organisation et l’hébergeur du dépôt), le domaine de l’adresse e-mail de commit, la branche actuelle et le dernier commit. Ils récupéraient également les valeurs d’intégration continue — les identifiants et la configuration qui permettent aux systèmes automatisés de compiler et de déployer du code sans qu’un humain saisisse un mot de passe à chaque fois.

Aucune de ces données ne permet de vider le compte bancaire de quelqu’un. Elles servent à autre chose : déterminer pour quelles entreprises travaille un développeur, à quoi ressemble leur infrastructure interne et comment y prendre pied.

Une faille notée 9,8 sur 10 dans la machine qui construit les logiciels

Le deuxième incident concerne TeamCity, une plateforme d’intégration et de livraison continues (CI/CD) créée par JetBrains. Si un éditeur de code est l’endroit où les développeurs écrivent les logiciels, une plateforme CI/CD est l’atelier automatisé où ce code est compilé, testé et envoyé en production — souvent sans qu’un humain clique une seule fois sur « déployer ». TeamCity est un élément central de cette machinerie dans de nombreuses entreprises.

Une vulnérabilité suivie sous le numéro CVE-2026-63077, avec un score de gravité de 9,8 sur 10, a été divulguée dans les versions sur site de TeamCity. Il s’agit d’une faille de désérialisation — une catégorie de bogue où un programme fait suffisamment confiance aux données entrantes pour les transformer directement en code exécutable, sans vérifier d’abord ce qu’elles sont réellement. En pratique, elle permettait à un attaquant d’envoyer une requête à un serveur TeamCity vulnérable, sans authentification, et d’exécuter des commandes arbitraires avec les mêmes privilèges que le service TeamCity lui-même. JetBrains a publié des correctifs (versions 2025.11.7 et 2026.1.3, ainsi qu’un plugin de correctif pour les installations plus anciennes en version 2017.1 ou ultérieure), mais la Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis a depuis averti que des attaquants exploitent activement les systèmes non corrigés.

Quiconque contrôle le serveur de compilation d’une entreprise contrôle ce que cette entreprise expédie. Ce n’est pas une hypothèse — c’est littéralement la fonction de cet outil.

Le même mode opératoire, deux portes différentes

Ces incidents sont sans lien et proviennent de chercheurs différents, mais ils présentent une structure commune. Aucun ne vise un produit fini. Tous deux attaquent une étape antérieure — l’éditeur dans lequel un développeur écrit du code, ou le serveur qui transforme ce code en version distribuée. C’est le trait caractéristique d’une attaque de la chaîne d’approvisionnement logicielle : au lieu de s’introduire dans une seule cible, on compromet un élément en amont dont dépendent de nombreuses cibles, puis on laisse leur propre processus de confiance transmettre l’accès à sa place.

Il vaut la peine d’être honnête sur ce que nous ignorons encore. Aucun des deux rapports publiés cette semaine ne fait état d’un cas confirmé où une application ou un utilisateur en aval aurait été compromis comme conséquence directe — la campagne visant les extensions ressemble à une opération de reconnaissance et de collecte d’accès, et l’exploitation de TeamCity est décrite comme active, mais sans victimes nommément désignées. C’est normal ; les compromissions de la chaîne d’approvisionnement sont souvent découvertes au point d’entrée, bien avant que les conséquences finales soient retracées — ou sans qu’elles le soient jamais.

Pourquoi c’est votre problème, pas seulement le leur

Vous n’installerez probablement jamais d’extension de programmation et vous n’exécuterez jamais de serveur CI/CD. Mais vous utilisez les résultats de centaines d’entre eux : votre application bancaire, votre gestionnaire de mots de passe, le portail scolaire de votre enfant, le navigateur dans lequel vous lisez ceci. Tout cela est passé par l’éditeur d’un développeur et le pipeline de compilation d’une entreprise avant d’atteindre votre téléphone. Si l’un ou l’autre de ces maillons est discrètement compromis, la modification malveillante peut se glisser avec une mise à jour logicielle ordinaire et habituelle — le genre de mise à jour que vous installez parce qu’on vous a dit que mettre à jour était la chose sûre à faire.

C’est aussi pourquoi les conseils d’un rapport d’incident postérieur à une fuite de données peuvent sembler étranges aux lecteurs non techniques : une entreprise explique que ses systèmes ont été compromis via un serveur de compilation, un identifiant de développeur volé ou une dépendance malveillante, et cela peut sembler abstrait à côté de « quelqu’un a deviné mon mot de passe ». Ce n’est pas abstrait. C’est le même résultat — vos données ou l’intégrité de votre application compromises — obtenu par une porte dont vous ignoriez l’existence.

Ce qui aide vraiment

Vous ne pouvez pas auditer le pipeline CI/CD de votre banque, et vous ne devriez pas avoir à le faire. Mais quelques habitudes réduisent réellement votre exposition à cette catégorie de risques :

Activez les mises à jour automatiques, mais ne considérez pas les mises à jour comme automatiquement dignes de confiance. Les correctifs sont le moyen par lequel des réparations comme celle de TeamCity mentionnée plus haut parviennent aux logiciels que vous utilisez — rester à jour ferme les brèches que les attaquants sondent activement. En même temps, une mise à jour n’est fiable qu’à la mesure du pipeline qui l’a produite, précisément la chose ciblée ici ; il n’existe aucune défense individuelle parfaite contre une version en amont véritablement empoisonnée, ce qui explique qu’il s’agisse fondamentalement d’un problème relevant de la responsabilité du fournisseur, et non d’un problème vous incombant.

Si vous travaillez avec des développeurs ou les encadrez, voici deux mesures concrètes et vérifiables : vérifiez que toute extension d’éditeur de code est installée depuis le véritable compte de l’éditeur vérifié, et pas seulement depuis un compte portant un nom correspondant (Open VSX et les marketplaces similaires affichent l’identité de l’éditeur — vérifiez-la, ne vous fiez pas uniquement à l’icône et au titre) ; et si votre organisation exécute TeamCity sur site, confirmez dès aujourd’hui qu’il est en version 2025.11.7 ou 2026.1.3, ou que le plugin de correctif est installé, plutôt que d’attendre la prochaine fenêtre de maintenance — l’avertissement de la CISA signifie que la faille est activement exploitée, et qu’il ne s’agit pas d’une hypothèse théorique.

Pour tous les autres, le changement utile consiste simplement à en prendre conscience : lorsque vous lisez qu’une fuite de données d’entreprise remonte à « un outil de développement compromis » ou à « un système de compilation », ce n’est pas une note technique marginale. C’est la même catégorie d’événement que les fuites de mots de passe et les arnaques par hameçonnage que cette newsletter couvre plus souvent — cela a simplement commencé un niveau plus haut dans la chaîne, avant même que le produit ne vous parvienne.