Ich verschob einen Ordner. Claude Code warnte mich vor meinen eigenen Geheimnissen.
Deine .env zu committen ist ein schwerer Fehler. API-Keys gestohlen, Credentials kompromittiert, das volle Desaster. Die Best Practice ist klar: .env in die .gitignore und du bist safe.
Nur schützt .gitignore dein Repository. Nicht deine Maschine.
Ein bösartiges CLI-Package liest nicht deine .gitignore. Es liest deine Festplatte. Es schnappt sich ~/.aws/credentials, deine Shell-History, deine SSH-Keys, deine Crypto-Wallets. Und jetzt liest es auch .claude/settings.local.json (eine Datei, die du wahrscheinlich nie geöffnet hast).
Das habe ich entdeckt, als ich meinen kompletten Dev-Ordner von iCloud runtergeholt habe, nachdem es meinen Node.js-Cache zerschossen hat. Claude Code hat mir gesagt, ich soll meine eigenen Secrets nicht kopieren. Ich habe 50 Projekte auditiert. Kein Secret liegt mehr im Klartext auf meiner Maschine.
TLDR: .gitignore ist ein Schloss an der Haustür. Malware kommt durchs Fenster. Infisical hinter einem Mesh-VPN injiziert Secrets zur Laufzeit. Nichts auf der Festplatte. Hier das Setup.
Das .gitignore-Theater
Jeder lacht über den Dev, der eine .env-Datei committed. Der Konsens steht fest, fünf Worte lang, wiederholt in jedem Bootcamp und jedem Twitter-Thread: pack es in die .gitignore.
Und klar. .gitignore ist entscheidend. Erste Verteidigungslinie. Sagt auch keiner was anderes.
Das Problem ist, sie als die letzte zu behandeln.
.gitignore sagt Git, was es überspringen soll. Das ist buchstäblich alles. Sie hat null Autorität über alles andere, was auf deiner Maschine läuft. Ein kompromittiertes npm-Package, eine vergiftete pip-Dependency, eine bösartige VS Code-Extension: keine davon checkt deine .gitignore, bevor sie deine Dateien liest. Müssen sie auch nicht. Sie haben Festplattenzugriff. Den hast du ihnen gegeben, in dem Moment, als du npm install ausgeführt hast.
Andrej Karpathy, ehemaliger AI-Chef bei Tesla und einer der Gründer von OpenAI, hat das auf die harte Tour mit LiteLLM gelernt. Er hat ein Typosquatting-Package gemeldet, das vollen Festplattenzugriff hatte: Shell-History, Cloud-Credentials, SSH-Keys, Docker-Configs, Kubernetes-Token. Alles in bekannten Pfaden, im Klartext, auf Entwicklermaschinen weltweit.
Eine Bedrohungsgruppe namens TeamPCP behauptet, 500.000 gestohlene Credentials über mehrere Kampagnen zu haben (selbst gemeldete Zahlen, nicht unabhängig verifiziert, aber die Exfiltrationstechnik ist dokumentiert und reproduzierbar).
Alle haben das Feuer gezeigt. Keiner hat den Feuerlöscher gezeigt.
Was deine Maschine tatsächlich preisgibt
Deine .gitignore deckt ein Verzeichnis ab. Malware deckt deinen ganzen Home-Ordner ab.
Die dokumentierte Exfiltration aus Supply-Chain-Attacken wie LiteLLM liest sich wie eine Einkaufsliste: ~/.aws/credentials, ~/.ssh/-Inhalte, jede .env-Datei in jedem Projekt (rekursive Suche, dauert Millisekunden), Shell-History mit jedem Token, den du eingefügt hast, weil du in Eile warst und dachtest "rotiere ich später" (hast du nicht), Docker-Registry-Credentials, Kubernetes-Token, Crypto-Wallets.
Und der neue Eintrag, den niemand überwacht: .claude/settings.local.json.
Der letzte ist, wie ich es rausgefunden habe. Ich habe ein Projekt nach ~/dev migriert, nachdem das iCloud-Chaos mich zwang, alles zu verschieben. Claude Code hat die Kopieroperation markiert. Sinngemäß: "Kopier deine Settings-Datei nicht, da sind Supabase-Secrets im Klartext in deinen auto-genehmigten Befehlen."
Das Tool, das das Leak verursacht hat, hat mich vor dem Leak gewarnt.
Ich hatte einen ganzen Artikel darüber geschrieben, wie CLAUDE.md die neue .env ist und wie die meisten Entwickler sie wie eine README behandeln. Während ich das geschrieben habe, hat der .claude/-Ordner still die echten Secrets geleakt. Nicht die CLAUDE.md-Datei selbst. Die Settings-Datei daneben, wo Claude Code jeden Befehl speichert, den du auto-genehmigt hast, wortwörtlich, inklusive derer mit deinen Datenbank-Credentials.
Das habe ich an einem Samstagmorgen entdeckt, während meine Kinder darüber gestritten haben, wer den letzten Pfannkuchen bekommt. Mein Bildschirm zeigte sieben Supabase-Keys im Klartext, und ich saß da und dachte "wie lange ist das schon so." Kein großartiger Pfannkuchen-Moment.
Die Woche, in der alles kaskadierte
Das war nicht geplant. Ich habe einen Ordner verschoben, und jeder Fix hat die nächste Schicht abgezogen.
iCloud hat meinen Node.js-Cache korrumpiert. Mysteriöse Crashes auf einer Maschine, die alles hätte schaffen sollen, was ich ihr vorwerfe. Der Fix war einfach: meine Projekte von ~/Documents/dev nach ~/dev verschieben, außerhalb von iClouds Sync-Radius. Problem gelöst.
Außer dass 50 Projekte verschieben bedeutet, 50 Projekte anzuschauen.
Da habe ich angefangen, Ordner zu öffnen, die ich monatelang nicht angefasst hatte. Überall alte .env-Dateien. Hardcodierte Token in Skripten, von denen ich vergessen hatte, dass sie existieren. Und dann das Dependency-Audit, das mich direkt zu einem Supply-Chain-Angriffsvektor in meinen pip-Dependencies geführt hat, den ich acht Monate lang blind auto-genehmigt hatte. Mein AI-Agent hat pip install auf alles ausgeführt, was er wollte, ohne Fragen zu stellen.
Die Dependencies zu sperren bedeutete, das Netzwerk zu sperren. Ich habe ein selbst-gehostetes Mesh-VPN aufgesetzt, das meine gesamte Infrastruktur vom öffentlichen Internet unsichtbar macht. Keine offenen Ports, keine exponierten Services, keine Angriffsfläche für Scanner.
Und das Mesh-VPN hat das letzte Stück freigelegt. Die Secrets selbst. Immer noch im Klartext auf der Festplatte, immer noch lesbar für alles mit Dateizugriff. Vier Probleme übereinander gestapelt, jedes unsichtbar, bis du das darüber repariert hast.
Wie Tapete in einem alten Haus zu entfernen und zu entdecken, dass die Wand dahinter von Optimismus zusammengehalten wird.
Infisical hinter dem Mesh
Also was ersetzt Klartext-Secrets auf der Festplatte?
Infisical. Open-Source-Secrets-Manager, selbst-gehostet, läuft im Mesh-VPN hinter Traefik. Nur erreichbar unter infisical.mesh:8080. Nicht dem Internet ausgesetzt. Wenn du keinen authentifizierten und verbundenen Netbird-Client hast, existiert diese Adresse einfach nicht.
Docker Compose, Postgres, Redis, auf demselben VPS, der den Rest meiner Sachen laufen lässt. Der Secrets-Manager selbst ist von außerhalb des Mesh unsichtbar. Das ist wichtig. Ein Secrets-Vault, der auf einer öffentlichen IP mit einer Login-Seite exponiert ist, ist nur ein schickeres Ziel. Meiner hat keine öffentliche IP. Keine Login-Seite, die von außen erreichbar ist. Keinen DNS-Eintrag, der darauf zeigt.
Ich habe sieben Secrets aus einem einzigen Projekt migriert. N8N_BASIC_AUTH_USER, SUPABASE_SERVICE_ROLE_KEY, VERCEL_OIDC_TOKEN und vier weitere. Alle vorher in .env-Dateien auf meiner Festplatte. Jetzt leben sie in Infisical, organisiert nach Projekt und Umgebung.
Der Workflow ändert sich kaum: infisical run -- npm start. Secrets zur Laufzeit geholt, als Umgebungsvariablen injiziert. Nichts auf die Festplatte geschrieben. Nichts bleibt bestehen, nachdem der Prozess stoppt.
Wenn Malware jetzt dein Dateisystem scannt, gibt es keine .env zu finden. Keine Credentials in der Shell-History. Keine Token in auto-genehmigten Befehlen.
Beim Aufräumen der node_modules nach dem Umzug bin ich auch zu Bun gewechselt. Kleinerer Footprint, kein riesiges node_modules-Verzeichnis, das da sitzt wie ein Buffet für alles, was das Dateisystem scannt. Keine Sicherheitsentscheidung, nur ein Nebeneffekt des Aufräumens. Weniger Oberfläche ist weniger Oberfläche.
Zwischen deinen Code auf Dependency-Vulnerabilities zu scannen und Secrets von der Festplatte zu entfernen deckst du zwei Gesichter derselben Haltung ab. Eines überwacht, was reinkommt. Das andere stellt sicher, dass nichts zu stehlen da ist, falls doch etwas durchkommt.
Das Schloss an der Tür und das offene Fenster
Der LiteLLM-Supply-Chain-Angriff hat gezeigt, was ein einziges vergiftetes Package anrichten kann. Shell-History gelesen, AWS-Credentials geschnappt, SSH-Keys kopiert. Dokumentiert, reproduzierbar, betrifft Tausende von Entwicklern. Niemand hat den Feuerlöscher gezeigt.
Öffne deine letzten drei Projekte. Frag dich, wo deine Secrets leben. Im Klartext auf der Festplatte? In einer .claude/settings.local.json, die du nie geöffnet hast? In der Shell-History, die ein bösartiges pip install in drei Sekunden lesen kann?
Ich habe meine Dev-Umgebung gesperrt. Keine Klartext-Secrets mehr. Kein Node.js-Cache mehr, der von Cloud-Sync korrumpiert wird. Keine Git-Repositories mehr, die von Dateisystem-Interferenzen kaputt gehen.
Ein Ordner-Move. Eine Woche Kaskade. Die Maschine ist sauber.
Quellen
Andrej Karpathys öffentliche Offenlegung des LiteLLM-Typosquatting-Angriffs. IntCyberDigest-Dokumentation zu TeamPCP-Exfiltrationstechniken und den Trivy-Supply-Chain-Vorfällen.
(*) Das Cover ist AI-generiert. Die Krabbe wurde während der Produktion nicht verletzt, aber deine .env-Datei schon.