Geheimnisse verfallen nicht durch Löschen: Git-Verlauf sicher bereinigen

Kurz gesagt: Ein in ein Repository eingecheckter API-Schlüssel bleibt lange nach dem Löschen der Datei im Verlauf. Erkennung, Rotation und eine Bereinigung des Verlaufs sind gemeinsam erforderlich – bloßes Löschen erzeugt nur ein falsches Sicherheitsgefühl.

Die Falle des Lösch-Commits

Wenn Entwickler eingecheckte Zugangsdaten entdecken, löschen sie oft die Zeile und pushen eine Korrektur. Das Geheimnis liegt jedoch weiterhin im Git-Verlauf und kann von jedem mit Klonzugriff abgerufen werden. War das Repository jemals öffentlich oder gespiegelt, muss der Schlüssel ab dem ersten Push als kompromittiert gelten.

Die einzig sichere Annahme lautet: Ein offengelegtes Geheimnis bleibt aktiv, bis es rotiert wurde.

Die richtige Reihenfolge der Behebung

• Zugangsdaten sofort rotieren – als kompromittiert behandeln, nicht nur als offengelegt.
• Den alten Schlüssel widerrufen und seine Nutzung während des Offenlegungszeitraums prüfen.
• Den Verlauf umschreiben, das Geheimnis aus allen erreichbaren Commits entfernen und Spiegel zwangsweise aktualisieren.
• Secret-Scanning vor Commits und in der CI einführen, damit der nächste Schlüssel vor dem Einchecken erkannt wird.

Erkennung muss kontinuierlich erfolgen

Secret-Leaks sind keine einmalige Aufräumaufgabe, sondern ein dauerhaftes Erkennungsproblem. Eine Prüfung nur beim Commit übersieht Geheimnisse, die über andere Wege gelangen. Eine rein historische Prüfung übersieht den Fehler von morgen. Beides ist notwendig.

KENSAI zeigt offengelegte Zugangsdaten zusammen mit dem Kontext an, der für die Rotation wichtig ist: welcher Schlüssel betroffen ist, wo er erreichbar ist und wie dringend die Offenlegung behoben werden muss.

So sieht gute Praxis aus

Behandle jedes Geheimnis, das jemals ein Repository berührt hat, als bereits offengelegt und gestalte Systeme so, dass diese Offenlegung beherrschbar bleibt. Kurzlebige, automatisch rotierte Zugangsdaten machen aus einem Leak ein Problem mit Ablaufdatum statt einer monatelang offenen Tür.

Verlagere die Erkennung nach vorn: Pre-Commit- und Pre-Receive-Hooks blockieren Geheimnisse, bevor sie aufgezeichnet werden. Serverseitige Scans fangen auf, was dennoch durchrutscht. Ziel ist keine einmalige Säuberung, sondern eine dauerhafte Kontrolle, die neue Leaks selten, sichtbar und schnell widerrufbar macht.

Fazit

Das Löschen eines offengelegten Geheimnisses ist der unwichtigste Schritt. Zuerst rotieren, dann den Verlauf bereinigen und anschließend kontinuierliche Erkennung etablieren, damit Offenlegungszeiträume schrumpfen, statt sich zu wiederholen.