Geheimnisse verlieren nicht ihre Gültigkeit, wenn Sie sie löschen: Git-Verlauf bereinigen

Kurz gesagt: Ein offengelegter API-Schlüssel, der in ein Repository eingecheckt wurde, bleibt noch lange nach dem Löschen der Datei im Verlauf erhalten. Erkennung, Rotation und das Umschreiben des Verlaufs sind allesamt erforderlich — das bloße Löschen vermittelt ein falsches Gefühl von Sicherheit.

Die Falle des Lösch-Commits

Wenn ein Entwickler eingecheckte Zugangsdaten bemerkt, besteht der erste Impuls darin, die Zeile zu löschen und eine Korrektur zu pushen. Das Geheimnis befindet sich jedoch weiterhin im Git-Verlauf und kann von jedem mit Zugriff auf einen Klon abgerufen werden. Wenn das Repository jemals öffentlich oder gespiegelt war, muss davon ausgegangen werden, dass das Geheimnis in dem Moment kompromittiert wurde, in dem es gepusht wurde.

Die einzig sichere Annahme ist, dass ein offengelegtes Geheimnis so lange gültig bleibt, bis es rotiert wurde.

Die richtige Reihenfolge der Behebung

• Rotieren Sie die Zugangsdaten sofort — behandeln Sie sie als kompromittiert, nicht nur als offengelegt.
• Widerrufen Sie den offengelegten Schlüssel und prüfen Sie seine gesamte Nutzung während des Offenlegungszeitraums.
• Schreiben Sie den Verlauf um, um das Geheimnis aus allen erreichbaren Commits zu entfernen, und erzwingen Sie die Aktualisierung aller Spiegel.
• Fügen Sie Secret-Scanning vor Commits und in CI hinzu, damit das nächste Geheimnis erkannt wird, bevor es eingecheckt wird.

Die Erkennung muss kontinuierlich erfolgen

Offengelegte Geheimnisse sind keine einmalige Bereinigungsaufgabe, sondern ein fortlaufendes Erkennungsproblem. Scans ausschließlich zum Commit-Zeitpunkt übersehen Geheimnisse, die über andere Wege gepusht werden, und rein historische Scans übersehen die Fehler von morgen. Beides ist wichtig.

Die Scans von KENSAI zeigen offengelegte Zugangsdaten mit dem nötigen Kontext an, um ihre Rotation zu priorisieren — welcher Schlüssel betroffen ist, wo er erreichbar ist und wie dringend die Offenlegung behoben werden muss.

So sieht gute Sicherheitshygiene in der Praxis aus

Behandeln Sie jedes Geheimnis, das jemals in einem Repository gespeichert war, als bereits offengelegt, und gestalten Sie Ihre Systeme so, dass eine solche Offenlegung verkraftbar ist. Kurzlebige, automatisch rotierte Zugangsdaten machen aus einem offengelegten Schlüssel ein Problem, das von selbst abläuft, statt zu einer offenen Tür zu werden, die monatelang offen bleibt.

Verlagern Sie die Erkennung mit Pre-Commit- und Pre-Receive-Hooks nach vorne, sodass ein Geheimnis blockiert wird, bevor es überhaupt aufgezeichnet werden kann, und ergänzen Sie dies durch serverseitige Scans, die alles abfangen, was dennoch durchrutscht. Das Ziel ist keine einmalige Bereinigung, sondern eine dauerhafte Kontrolle, die neue Offenlegungen selten und unübersehbar macht und ihren schnellen Widerruf ermöglicht.

Fazit

Das Löschen eines offengelegten Geheimnisses ist der unwichtigste Schritt. Rotieren Sie es zuerst, bereinigen Sie anschließend den Verlauf und richten Sie eine kontinuierliche Erkennung ein, damit sich Offenlegungszeiträume verkürzen, statt sich zu wiederholen.