Secrets verschwinden nicht, wenn du sie löschst: Git-History bereinigen

Ein geleakter API-Key, der in ein Repo committet wurde, bleibt lange in der History, nachdem die Datei gelöscht ist. Detection, Rotation und History-Rewriting sind alle erforderlich – Löschen allein ist eine falsche Sicherheit.

Kurz gefasst: Ein geleakter API-Key, der in ein Repo committet wurde, bleibt lange in der History, nachdem die Datei gelöscht ist. Detection, Rotation und History-Rewriting sind alle erforderlich – Löschen allein ist eine falsche Sicherheit.

Die Delete-Commit-Falle

Wenn ein Entwickler ein committetes Credential bemerkt, ist der Instinkt, die Zeile zu löschen und einen Fix zu pushen. Aber das Secret sitzt weiterhin in der Git-History, abrufbar für jeden mit Clone-Zugriff. War das Repo je öffentlich oder gespiegelt, nimm an, dass das Secret in dem Moment kompromittiert wurde, in dem es gepusht wurde.

Die einzig sichere Annahme ist, dass ein geleaktes Secret ein aktives Secret ist, bis es rotiert wird.

Die echte Remediation-Sequenz

• Rotiere das Credential sofort – behandle es als kompromittiert, nicht nur als exponiert.
• Widerrufe und auditiere jede Nutzung des geleakten Keys während des Exposure-Fensters.
• Schreibe die History um, um das Secret aus allen erreichbaren Commits zu purgen, und erzwinge ein Refresh der Mirrors.
• Füge Pre-Commit- und CI-Secret-Scanning hinzu, damit das nächste vor dem Landen gefangen wird.

Detection muss kontinuierlich sein

Secret-Leaks sind kein einmaliges Aufräumen; sie sind ein fortlaufendes Detection-Problem. Nur zur Commit-Zeit zu scannen verpasst Secrets, die über andere Pfade gepusht werden, und nur historisch zu scannen verpasst den Fehler von morgen. Beides zählt.

KENSAIs Scanning legt exponierte Credentials mit dem Kontext offen, der nötig ist, um Rotation zu priorisieren – welcher Key, wo er erreichbar ist und wie dringend die Exposure ist.

Wie gute Hygiene in der Praxis aussieht

Behandle jedes Secret, das je ein Repository berührt hat, als bereits exponiert, und gestalte so, dass Exposure überlebbar ist. Kurzlebige, automatisch rotierte Credentials verwandeln einen geleakten Key in ein Problem, das von selbst abläuft, statt in eine offene Tür, die monatelang offen bleibt.

Verschiebe Detection nach links mit Pre-Commit- und Pre-Receive-Hooks, die ein Secret blockieren, bevor es je aufgezeichnet wird, und paare das mit serverseitigem Scanning, das fängt, was durchrutscht. Das Ziel ist kein einmaliges Aufräumen, sondern eine stehende Kontrolle, die neue Leaks selten, laut und schnell widerrufbar macht.

Fazit

Ein geleaktes Secret zu löschen ist der unwichtigste Schritt. Rotiere zuerst, purge die History als Zweites und richte kontinuierliche Detection ein, damit Exposure-Fenster schrumpfen, statt sich zu wiederholen.