Eingecheckte Secret-Dateien

Was ist Eingecheckte Secret-Dateien?

Ein Problem besteht darin, ein Geheimnis in der Quelle fest zu kodieren. Eine ganze Datei davon zu übertragen, ist eine andere Sache. Ein Repository ohne .gitignore verfolgt .env-Dateien, private Schlüssel und Dienstkonto-JSON ab dem ersten Commit. Sobald eine Datei verfolgt wird, gehört sie zum Verlauf, sodass jeder Klon eine Kopie enthält. Sie klonen ein öffentliches Repository, lesen ein festgeschriebenes .env und erreichen eine Live-Staging-Umgebung. Dann entfernen Sie die Dateien mit git rm --cached, rotieren jeden offengelegten Schlüssel, fügen einen .gitignore hinzu und installieren einen Pre-Commit-Hook, der geheime Dateinamen blockiert.

Was Sie lernen in Eingecheckte Secret-Dateien

• Erkennen, dass eine fehlende oder unvollständige .gitignore dazu führt, dass eine komplette Secret-Datei — eine .env, ein privater Schlüssel oder eine Service-Account-JSON — schon mit dem ersten Commit eingecheckt und erfasst wird
• Verstehen, warum jeder Klon eines öffentlichen Repos eine Kopie einer erfassten Secret-Datei enthält und sich die Offenlegung deshalb nicht durch späteres Löschen der Datei rückgängig machen lässt
• Das Einchecken einer Secret-DATEI unter Versionskontrolle von einem fest im Quellcode hinterlegten Secret unterscheiden — und wissen, dass beides nicht ins Repo gehört
• Die Aufräumarbeiten durchführen: die Dateien mit git rm --cached aus der Versionskontrolle nehmen und die offengelegten Schlüssel rotieren, weil jedes gepushte Secret als kompromittiert gilt
• Eine Wiederholung verhindern — mit einer .gitignore, die Secret-Dateien abdeckt, plus einem Pre-Commit-Hook, der bekannte Secret-Dateinamen blockiert, bevor sie eingecheckt werden

Eingecheckte Secret-Dateien — Trainingsschritte

1. Das Ziel auskundschaften

   Heute hat Bob Tavonn im Visier, ein Startup für Zahlungsintegrationen, das einen Teil seines Codes offen veröffentlicht. Er beginnt beim öffentlichen Repository und verschafft sich einen Überblick darüber, womit das Unternehmen arbeitet, bevor er nach einem Einstieg sucht. Ein öffentliches Repo ist ein Geschenk für jemanden wie Bob: das ganze Projekt, jede einzelne Datei, mit einem einzigen Befehl herunterladbar.

2. Das Repo klonen

   Bob klont das Repository auf seinen eigenen Rechner, um jede erfasste Datei offline und in aller Ruhe zu lesen. Alles, was das Repo erfasst, kommt beim Klonen mit. Wurde jemals eine Secret-Datei eingecheckt, liegt sie in der Kopie, die er sich gerade geholt hat.

3. Die erfassten Dateien auflisten

   Bob lässt sich auflisten, was das Repository alles erfasst. Ihn interessiert nicht, was auf der Festplatte liegt, sondern welche Dateien tatsächlich unter Versionskontrolle stehen — denn genau die trägt jeder Klon mit sich.

4. Die Secret-Datei lesen

   Bob öffnet die eingecheckte Environment-Datei. Genau darin unterscheidet sich dieses Leak von einem einzelnen fest im Code hinterlegten Schlüssel: Es ist kein einzelner Wert, der in eine Codezeile kopiert wurde, sondern eine komplette Datei voller Secrets unter Versionskontrolle. Alles, was der Service zum Laufen braucht, steht hier im Klartext.

5. Die Staging-Umgebung erreichen

   Ein geleakter Schlüssel bleibt Theorie, solange er nichts öffnet. Aus dem Klon hat Bob bereits alles beisammen: Die eingecheckte .env liefert ihm die Basis-URL der API in PUBLIC_API_URL und einen aktiven Schlüssel, und die mitgeklonten Routen in src/routes/payments.js definieren den Zahlungs-Feed unter /v1/transactions . Er baut die Anfrage zusammen und führt den Schlüssel in einem Authorization-Header mit, genau wie es ein echter Client täte. Geheim waren die Endpunkte nie — sie stehen im öffentlichen Quellcode. Der Schlüssel war es, und genau den hat ihm die eingecheckte Datei in die Hand gedrückt; der Server hat also keinen Grund, die Anfrage abzulehnen.

6. Die Zahlungsdaten liegen offen

   Der Server hat dem Schlüssel vertraut und geantwortet. Bob liest Tavonns Zahlungsdatensätze aus der Staging-Umgebung — von außerhalb des Unternehmens und ohne ein eigenes Konto.

7. Wissenscheck

   Sie haben gerade gesehen, wie ein öffentliches Repo einem Außenstehenden die Schlüssel zu einer laufenden Umgebung überreicht hat. Prägen Sie sich ein, warum.

8. Der Alarm trifft ein

   Sie verantworten Tavonns Repo payments-service. Über Nacht hat der Secret-Scanner des Security-Teams das öffentliche Repository markiert und Ihnen eine E-Mail geschickt. Der Befund ist unmissverständlich: Im öffentlichen Repo liegt eine eingecheckte .env mit aktiven Schlüsseln, und es gibt keine .gitignore , die solche Dateien draußen hält.

9. Erfasst, ganz ohne .gitignore

   Ihr erster Schritt: sich selbst ein Bild machen. Sie lassen sich auflisten, was Git im Repo erfasst — und da steht es: Die .env und der Service-Account-Schlüssel stehen unter Versionskontrolle, und eine .gitignore fehlt in der Liste. Eine Datei auf der Festplatte ist das eine; eine Datei, die Git erfasst, ist eingecheckt, steht in der Historie und liegt in jedem Klon.

10. Die Secret-Dateien aus der Versionskontrolle nehmen

    Mit git rm --cached sorgen Sie dafür, dass Git die Secret-Dateien nicht mehr erfasst: Der Befehl nimmt sie aus dem Index, lässt sie aber auf der Festplatte liegen, damit der Service lokal weiterläuft. Sie committen und pushen die Änderung, und die Dateien verschwinden aus dem aktuellen Repo. Das fühlt sich nach der Lösung an. Sie ist es nicht — warum, zeigt der nächste Schritt.