J'ai Déplacé un Dossier. Claude Code M'a Dit de Ne Pas Copier Mes Propres Secrets.
Commiter votre .env est une erreur grave. Clés API volées, identifiants exposés, catastrophe totale. La bonne pratique est claire : mettez votre .env dans .gitignore et vous êtes protégé.
Sauf que .gitignore protège votre repo. Pas votre machine.
Un package CLI malveillant ne lit pas votre .gitignore. Il lit votre disque. Il récupère ~/.aws/credentials, votre historique shell, vos clés SSH, vos portefeuilles crypto. Et maintenant il lit aussi .claude/settings.local.json (un fichier que vous n'avez probablement jamais ouvert).
J'ai découvert ça en déplaçant tout mon dossier dev hors d'iCloud après qu'il ait corrompu mon cache Node.js. Claude Code m'a dit de ne pas copier mes propres secrets. J'ai audité 50 projets. Plus aucun secret ne vit en clair sur ma machine.
TLDR : .gitignore est un verrou sur la porte d'entrée. Les malwares passent par la fenêtre. Infisical derrière un VPN mesh injecte les secrets à l'exécution. Rien sur le disque. Voici la config.
Le Théâtre du .gitignore
Tout le monde se moque du dev qui commit un fichier .env. Le consensus est établi, cinq mots répétés dans chaque bootcamp et chaque thread Twitter : mettez-le dans .gitignore.
Et c'est vrai. .gitignore est crucial. Première ligne de défense. Personne ne dit le contraire.
Le problème, c'est de le traiter comme la dernière.
.gitignore dit à Git quoi ignorer. C'est littéralement tout ce qu'il fait. Il n'a aucune autorité sur quoi que ce soit d'autre qui tourne sur votre machine. Un package npm compromis, une dépendance pip empoisonnée, une extension VS Code véreuse : aucun ne vérifie votre .gitignore avant de lire vos fichiers. Ils n'en ont pas besoin. Ils ont accès au disque. Vous le leur avez donné dès que vous avez lancé npm install.
Andrej Karpathy, ancien responsable IA chez Tesla et l'un des fondateurs d'OpenAI, l'a appris à ses dépens avec LiteLLM. Il a signalé un package typosquatté qui avait un accès complet en lecture au disque : historique shell, identifiants cloud, clés SSH, configs Docker, tokens Kubernetes. Tout ce qui traîne dans des chemins connus, en clair, sur les machines de développeurs du monde entier.
Un groupe de menaces qui se fait appeler TeamPCP revendique 500 000 identifiants volés à travers plusieurs campagnes (chiffres auto-déclarés, non vérifiés indépendamment, mais la technique d'exfiltration est documentée et reproductible).
Tout le monde a montré l'incendie. Personne n'a montré l'extincteur.
Ce Que Votre Machine Expose Vraiment
Votre .gitignore couvre un répertoire. Les malwares couvrent tout votre dossier home.
L'exfiltration documentée des attaques de supply chain comme LiteLLM ressemble à une liste de courses : ~/.aws/credentials, contenu de ~/.ssh/, tous les fichiers .env de tous les projets (recherche récursive, prend quelques millisecondes), historique shell avec tous les tokens que vous avez collés parce que vous étiez pressé et vous vous êtes dit "je le ferai tourner plus tard" (vous ne l'avez pas fait), identifiants de registres Docker, tokens Kubernetes, portefeuilles crypto.
Et la nouvelle entrée que personne ne surveille : .claude/settings.local.json.
Cette dernière, c'est comme ça que je l'ai découvert. Je migrais un projet vers ~/dev après que le bordel iCloud m'ait forcé à tout déplacer. Claude Code a signalé l'opération de copie. En paraphrasant : "Ne copiez pas votre fichier de paramètres, il y a des secrets Supabase en clair dans vos commandes auto-approuvées."
L'outil qui avait créé la fuite m'avertissait de la fuite.
J'avais écrit tout un article sur comment CLAUDE.md est le nouveau .env et comment la plupart des développeurs le traitent comme un README. Pendant que j'écrivais ça, le dossier .claude/ fuyait discrètement les vrais secrets. Pas le fichier CLAUDE.md lui-même. Le fichier de paramètres à côté, où Claude Code stocke chaque commande que vous auto-approuvez, mot pour mot, y compris celles avec vos identifiants de base de données.
J'ai trouvé ça un samedi matin pendant que mes enfants se disputaient pour savoir qui aurait la dernière crêpe. Mon écran affichait sept clés Supabase en clair, et j'étais là à me dire "depuis combien de temps c'est comme ça". Pas un super moment crêpe.
La Semaine Où Tout S'Est Enchaîné
Ce n'était pas prévu. J'ai déplacé un dossier, et chaque correction a révélé la couche suivante.
iCloud corrompait mon cache Node.js. Crashes mystérieux sur une machine qui aurait dû gérer tout ce que je lui lançais. La solution était simple : déplacer mes projets de ~/Documents/dev vers ~/dev, hors du rayon de sync d'iCloud. Problème résolu.
Sauf que déplacer 50 projets, ça veut dire regarder 50 projets.
C'est là que j'ai commencé à ouvrir des dossiers que je n'avais pas touchés depuis des mois. Des vieux fichiers .env partout. Des tokens hardcodés dans des scripts que j'avais oubliés. Et puis l'audit des dépendances, qui m'a mené droit à un vecteur d'attaque de supply chain caché dans mes dépendances pip que j'auto-approuvais aveuglément depuis huit mois. Mon agent IA lançait pip install sur ce qu'il voulait, sans poser de questions.
Verrouiller les dépendances voulait dire verrouiller le réseau. J'ai mis en place un VPN mesh auto-hébergé qui rend toute mon infrastructure invisible depuis l'internet public. Pas de ports ouverts, pas de services exposés, pas de surface d'attaque pour les scanners.
Et le VPN mesh a révélé la dernière pièce. Les secrets eux-mêmes. Toujours assis en clair sur le disque, toujours lisibles par n'importe quoi avec accès aux fichiers. Quatre problèmes empilés les uns sur les autres, chacun invisible jusqu'à ce que vous corrigiez celui du dessus.
Comme enlever du papier peint dans une vieille maison et découvrir que le mur derrière tient par l'optimisme.
Infisical Derrière le Mesh
Alors qu'est-ce qui remplace les secrets en clair sur le disque ?
Infisical. Gestionnaire de secrets open source, auto-hébergé, qui tourne dans le VPN mesh derrière Traefik. Accessible uniquement à infisical.mesh:8080. Pas exposé sur internet. Si vous n'avez pas un client Netbird authentifié et connecté, cette adresse n'existe tout simplement pas.
Docker Compose, Postgres, Redis, assis sur le même VPS qui fait tourner le reste de mes trucs. Le gestionnaire de secrets lui-même est invisible depuis l'extérieur du mesh. C'est important. Un coffre-fort de secrets exposé sur une IP publique avec une page de login n'est qu'une cible plus fancy. Le mien n'a pas d'IP publique. Pas de page de login accessible de l'extérieur. Pas d'entrée DNS qui pointe dessus.
J'ai migré sept secrets d'un seul projet. N8N_BASIC_AUTH_USER, SUPABASE_SERVICE_ROLE_KEY, VERCEL_OIDC_TOKEN, et quatre autres. Tous précédemment dans des fichiers .env sur mon disque. Maintenant ils vivent dans Infisical, organisés par projet et environnement.
Le workflow change à peine : infisical run -- npm start. Secrets récupérés à l'exécution, injectés comme variables d'environnement. Rien d'écrit sur le disque. Rien ne persiste après l'arrêt du processus.
Si un malware scanne votre système de fichiers maintenant, il n'y a pas de .env à trouver. Pas d'identifiants dans l'historique shell. Pas de tokens dans les commandes auto-approuvées.
En nettoyant node_modules après le déménagement, je suis aussi passé à Bun. Empreinte plus petite, pas d'énorme répertoire node_modules qui traîne comme un buffet pour tout ce qui scanne le système de fichiers. Pas une décision de sécurité, juste un effet de bord du nettoyage. Moins de surface, c'est moins de surface.
Entre scanner votre code pour les vulnérabilités de dépendances et retirer les secrets du disque, vous couvrez deux faces de la même posture. L'une surveille ce qui entre. L'autre s'assure qu'il n'y a rien à voler si quelque chose passe.
Le Verrou sur la Porte et la Fenêtre Ouverte
L'attaque de supply chain LiteLLM a montré ce qu'un seul package empoisonné peut faire. Historique shell lu, identifiants AWS récupérés, clés SSH copiées. Documenté, reproductible, affectant des milliers de développeurs. Personne n'a montré l'extincteur.
Ouvrez vos trois derniers projets. Demandez-vous où vivent vos secrets. En clair sur le disque ? Dans un .claude/settings.local.json que vous n'avez jamais ouvert ? Dans un historique shell qu'un pip install malveillant peut lire en trois secondes ?
J'ai verrouillé mon environnement de dev. Plus de secrets en clair. Plus de cache Node.js corrompu par la sync cloud. Plus de dépôts git cassés par les interférences du système de fichiers.
Un déplacement de dossier. Une semaine de cascade. La machine est propre.
Sources
Divulgation publique d'Andrej Karpathy de l'attaque de typosquatting LiteLLM. Documentation IntCyberDigest sur les techniques d'exfiltration TeamPCP et les incidents de supply chain Trivy.
(*) La couverture est générée par IA. Le crabe n'a pas été blessé pendant la production, mais votre fichier .env l'a été.