Il ne devrait rien y avoir à récolter

Hier, une version compromise de l'CLI de Bitwarden a récolté des clés SSH, des identifiants AWS, des jetons npm, des variables d'environnement, des historiques de shell et des secrets Git sur 334 machines de développeurs.

Aujourd'hui, c'était Bitwarden. Le mois dernier, Axios. Avant cela, Checkmarx. Demain, ce sera une extension VS Code, ou Acrobat, ou une formule Homebrew, ou une image Docker. Le vecteur change chaque semaine. Le résultat est toujours le même.

Le logiciel malveillant s'installe. Il lit ~/.ssh/. Il lit ~/.aws/credentials. Il lit ~/.npmrc. Il lit ~/.git-credentials. Il lit les historiques de shell, les variables d'environnement, les coffres de mots de passe des navigateurs. Il empaquette tout et l'envoie à un serveur C2.

Et cela fonctionne. À chaque fois.

La récolte

La charge de Bitwarden — un fichier obfuscaté de 10 Mo nommé bw1.js — n'a pas cherché à casser de chiffrement. Elle n'en avait pas besoin. Voici ce qu'elle a collecté, comme documenté par Socket et Aikido :

• Clés SSH et empreintes d'hôtes
• Identifiants cloud AWS, GCP et Azure
• Jetons d'authentification npm
• Identifiants Git et URL distantes
• Variables d'environnement
• Historiques de shell
• Authentification Claude Code et configurations MCP

Elle a ensuite utilisé les jetons npm volés pour republier d'autres paquets maintenus par la victime, se propageant ainsi plus loin. Les victimes sont devenues des vecteurs.

Rien de tout cela n'a exigé de casser un chiffrement. Chacun de ces secrets était un fichier sur le système de fichiers, lisible par tout processus s'exécutant sous l'utilisateur.

Ce n'est pas une histoire de Bitwarden

Le chiffrement du coffre de Bitwarden n'a pas été compromis. Leur architecture à connaissance zéro a tenu. Le logiciel malveillant n'a jamais touché au coffre.

Il n'en avait pas besoin.

Le coffre protège ce qu'il contient. Mais les clés SSH n'étaient pas dans le coffre. Les identifiants AWS n'étaient pas dans le coffre. Les jetons npm, les identifiants Git, les clés API dans les fichiers .env — rien de tout cela ne vit dans un gestionnaire de mots de passe. Cela vit dans des fichiers de configuration, en clair, sur la machine de chaque développeur.

L'attaquant l'avait compris. Le coffre est un coffre-fort verrouillé dans une maison où chaque tiroir est ouvert.

La véritable surface d'attaque

Ouvrez un terminal maintenant. Regardez ce qui se trouve sur votre machine.

~/.ssh/id_ed25519 — votre clé privée. Fichier en clair.

~/.aws/credentials — votre accès cloud. Fichier en clair.

~/.npmrc — votre jeton de publication. Fichier en clair.

~/.git-credentials — votre accès aux dépôts. Fichier en clair.

~/.env dans une dizaine de répertoires de projets — clés API, mots de passe de bases de données, secrets de signature. Tous en clair.

Tout processus s'exécutant sous votre utilisateur peut lire l'ensemble. Aucune élévation de privilèges nécessaire. Aucun exploit requis. Simplement cat.

C'est la configuration de développeur par défaut en 2026. Nous mettons nos mots de passe dans un coffre chiffré et laissons tout le reste à découvert.

La mauvaise question

Après chaque attaque de la chaîne d'approvisionnement, l'industrie pose la même question : comment empêcher le logiciel malveillant d'entrer ?

Une meilleure sécurité CI/CD. La signature de code. L'analyse des dépendances. Les environnements d'exécution cloisonnés. Tout cela est utile. Rien de tout cela ne suffit. La surface d'attaque est trop vaste. Il y a trop de vecteurs — gestionnaires de paquets, extensions de navigateur, plugiciels d'IDE, applications OAuth, outils de build compromis. Vous ne pouvez pas sceller chaque point d'entrée.

La bonne question est : lorsque le logiciel malveillant obtient inévitablement l'exécution sur la machine d'un développeur, que trouve-t-il ?

Si la réponse est « des centaines d'identifiants en clair dans des emplacements prévisibles du système de fichiers », aucun durcissement de la chaîne d'approvisionnement ne compte. Vous jouez la défense sur un terrain où le but est grand ouvert derrière vous.

Il ne devrait rien y avoir à récolter

La solution n'est pas une meilleure détection des logiciels malveillants. La solution n'est pas de cloisonner npm install. La solution n'est pas un temps de réponse aux incidents plus rapide.

La solution est : les secrets ne devraient pas exister sous forme de fichiers sur le disque.

Des clés SSH dérivées du matériel au moment de l'authentification — pas stockées dans ~/.ssh/. Des identifiants cloud émis par session à partir d'une identité liée au matériel — pas écrits dans ~/.aws/. Des jetons API limités en périmètre, éphémères et conditionnés par le matériel — pas laissés dans des fichiers .env.

Lorsqu'un identifiant n'existe que dans un module de sécurité matériel et en mémoire processus éphémère pendant son utilisation, il n'y a rien que le logiciel malveillant puisse lire. Aucun fichier à exfiltrer. Aucun fichier de configuration à récupérer. Le processus s'exécute, ne trouve rien, passe son chemin.

Ce n'est pas théorique. Des identifiants liés au matériel existent aujourd'hui. WebAuthn PRF peut dériver des clés cryptographiques à partir d'une interaction physique avec un authentificateur — des clés qui ne touchent jamais le système de fichiers. La technologie est là. L'industrie ne l'a simplement pas adoptée comme valeur par défaut.

Que faire maintenant

Si vous avez été affecté par la compromission de l'CLI de Bitwarden :

• Faites pivoter chaque identifiant sur la machine — clés SSH, jetons cloud, jetons npm, clés API, tout ce qui se trouve dans les fichiers de configuration et les variables d'environnement
• Vérifiez si des paquets npm que vous maintenez ont été republiés
• Auditez l'activité GitHub et les workflows CI/CD à la recherche de modifications non autorisées

Si vous n'avez pas été affecté, l'action est la même. Regardez votre machine. Comptez les secrets en clair. Demandez-vous ce qui se passe lorsque — et non si — quelque chose de malveillant s'exécute sous votre utilisateur.

La réponse devrait être : rien. Il ne devrait rien y avoir à récolter.