Le logiciel malveillant était signé par Red Hat
Cette semaine, du code de vol d'identifiants a atteint des développeurs sous le nom de Red Hat. La menace ne venait pas de l'extérieur de votre cercle de confiance — elle venait de l'intérieur. Vous ne pouvez pas résoudre cela par la vérification. Vous pouvez tenir vos identifiants hors de portée.
Cette semaine, du code signé par Red Hat a tenté de voler vos identifiants.
Des attaquants ont pénétré dans le compte d'un développeur Red Hat et ont publié des versions altérées de paquets officiels Red Hat. Dès qu'une machine en installait un, du code caché s'exécutait automatiquement et cherchait tout ce qu'il pouvait trouver de précieux — clés cloud, jetons d'accès, identifiants, tout ce qui ouvre une porte. Puis il utilisait ce qu'il avait volé pour se propager.
Observez la forme de cette attaque. Red Hat n'était pas la cible — c'était vous. Leur nom, leur compte de confiance, le pipeline d'installation que vous avez utilisé mille fois sans y penser : ce n'est pas cela qui a été la victime. C'était l'arme. L'attaque n'a pas contourné votre cercle de confiance. Elle est entrée par la grande porte avec un badge que vous aviez vous-même délivré. C'est ce qui distingue les attaques sur la chaîne d'approvisionnement de tout le reste — le danger n'est pas un inconnu que vous pouvez bloquer, c'est le fournisseur que vous aviez déjà décidé de confiance, qui livre la charge utile pour vous. Et il s'agissait de Red Hat : l'une des entreprises les plus matures en matière de sécurité qui soient, avec une revue réelle et un budget réel. Le code malveillant a quand même été livré sous leur nom.
Voici donc la conclusion que vous ne pouvez pas éluder : si Red Hat ne peut pas garantir que ce que vous installez chez eux est propre, personne ne le peut. Ni votre framework, ni votre fournisseur CI, ni la dépendance à trois niveaux de profondeur que vous n'avez jamais lue. Vous finirez par exécuter du code que vous n'avez pas écrit et que vous n'avez pas pu vérifier entièrement. Ce n'est pas une défaillance de processus — c'est ce que signifie construire sur le logiciel des autres.
Continuez à analyser. Continuez à figer les versions. Continuez à vérifier. Tout cela vaut la peine d'être fait — mais ne vous y fiez pas, car cette semaine rien de cela n'aurait aidé : le logiciel malveillant arrivait déjà en position de confiance. La vraie question n'est pas de savoir comment empêcher le code malveillant d'entrer. C'est celle-ci : lorsque du code malveillant s'exécute sur votre machine, avez-vous protégé vos secrets ?
Pour presque tout le monde, la réponse honnête est non. Regardez ce que cette attaque a récupéré — variables d'environnement, jetons posés dans des fichiers, puis elle s'est présentée aux gestionnaires de secrets cloud et leur a demandé de livrer leur contenu. C'est ainsi que vivent les identifiants en 2026 : empilés en un seul endroit, à portée de main de tout ce qui se trouve exécuté. Une mauvaise installation ne prend pas un seul secret. Elle prend tous les secrets, puis se propage.
La solution consiste à ne plus conserver vos identifiants là où votre code peut les saisir. Gardez-les à distance de bras.
C'est toute l'idée du fonctionnement de Clavitor. Vos secrets ne vivent pas dans votre environnement ; rien n'attend dans un fichier .env pour être lu. Un programme — ou un agent IA — ne détient jamais l'identifiant. Il obtient la capacité de l'utiliser, récupéré à la demande au moment exact où il est nécessaire — jamais stocké, jamais mis en cache — depuis l'un de nos 21 emplacements répartis sur six continents, de sorte que la copie la plus proche est toujours à quelques millisecondes, limitée au seul secret qui lui a été accordé, chaque accès étant journalisé. Lorsqu'un script d'installation malveillant tâtonne à la recherche de clés, il trouve une pièce vide.
Et nous partons du principe qu'un identifiant finira par être capturé : ce qu'un agent transporte est donc presque inutile s'il est volé. Il ne fonctionne que depuis la machine à laquelle il a été délivré — dérobez-le et exécutez-le depuis les propres serveurs de l'attaquant, et il est refusé. Il est limité en débit et surveillé : quelques secrets par minute, pour qu'il ne puisse pas aspirer l'intégralité de votre coffre, et dès qu'il dépasse sa poignée habituelle, il déclenche une alerte et se verrouille. La stratégie entière d'un ver — tout prendre vite, tout utiliser partout — se heurte à un mur.
Aucune promesse d'immunité : si un identifiant est en cours d'utilisation au moment exact où le logiciel malveillant s'exécute, celui-là peut être capturé — aucune architecture ne réécrit les lois de la physique. Mais c'est justement le point. L'attaque Red Hat a été dévastatrice parce qu'une seule installation pouvait vider un dépôt de secrets entier et le retourner en arme. La distance de bras, plus un identifiant lié à une seule machine et limité à un filet, transforme « ils ont tout pris et se sont propagés » en « ils ont peut-être capturé une clé en vol, et elle n'a fonctionné nulle part ailleurs ». C'est la distance qui sépare une catastrophe d'une note de bas de page.
Le logiciel malveillant était signé par Red Hat. Vous ne le battrez pas par la vérification. Partez du principe que le code entre — et faites en sorte que, quand il le fait, vos secrets ne soient pas là à l'attendre.
(Suivi publiquement sous le nom de « Miasma », une variante de la famille de vers npm auto-propagés Shai-Hulud. Les analyses techniques valent votre temps ; ce billet porte sur la partie qui ne change pas d'une attaque à l'autre.)
Sources :