Dein Blog zum Thema digitales Business

Ein Fund ist kein Problem, das du gelöst hast

Ein Secret-Scanner durchsucht ein Repository nach Mustern, die wie Zugangsdaten aussehen: API-Keys, Tokens, Passwörter, Zertifikate. Findet er etwas, bekommst du eine Meldung, vielleicht blockiert der Scanner den Push sogar automatisch, bevor das Secret in die Historie gelangt. Das ist wertvoll. Aber es beantwortet nur eine von zwei Fragen: Ist das Secret sichtbar? Die zweite Frage bleibt offen: Ist das Secret noch gültig?

Diese zweite Frage übersieht man leicht, weil der Scan wie ein Abschluss wirkt. Die Meldung ist weg, der Build ist grün, das Ticket ist geschlossen. Nur: der Token, der im Commit stand, funktioniert danach noch genauso wie vorher. Wenn er einmal außerhalb des Repos gelandet ist, in einem Fork, einem CI-Log, einem Backup, einer lokalen Kopie, bleibt er so lange ein funktionierendes Zugangsmittel, bis ihn jemand aktiv ungültig macht.

Scan und Rotation lösen unterschiedliche Probleme

Ein Scan ist eine Sichtbarkeitskontrolle. Er sagt dir, wo ein Secret im Code oder in der Historie steht. Rotation ist eine Gültigkeitskontrolle. Sie sagt: dieses Secret gilt ab jetzt nicht mehr, ein neues tritt an seine Stelle. Beide Kontrollen ergänzen sich, ersetzen sich aber nicht.

Das unterscheidet dieses Thema von der Frage, welche Art von Zugang ein Dienst überhaupt bekommt. Bei Service-Accounts und Bot-Tokens geht es darum, welche Identität hinter einem Zugriff steht und ob sie auf einer Liste geführt wird. Bei Deploy Keys und GitHub Apps geht es um den Mechanismus, über den eine Maschine überhaupt Zugriff bekommt. Rotation setzt bei beidem erst an, sobald der Zugang existiert: Wie lange bleibt ein einmal ausgegebenes Secret gültig, und wer macht es ungültig, wenn es Zeit dafür ist?

Auch von einem früheren Beitrag zu Deploy-Key-Ablaufdaten unterscheidet sich das: dort ging es um eine einzelne Zugangsart mit technisch eingebautem Verfallsdatum, hier um den Rotationsprozess für Secrets aller Art, unabhängig davon, ob der ausstellende Dienst selbst ein Ablaufdatum kennt.

Warum ein Fund im Scan die Gefahr nicht bannt

Nimm ein klassisches Beispiel: ein API-Key landet versehentlich in einem Commit, der Scanner schlägt Alarm, jemand entfernt den Key aus dem Code und pusht die Korrektur. Der Scan ist jetzt sauber. Trotzdem bleibt der Key aktiv, wenn niemand ihn beim ausstellenden Dienst widerrufen oder ersetzt hat. Git-Historie lässt sich zwar bereinigen, aber jede Kopie, die vorher gezogen wurde, enthält den alten Stand weiter. Und ein Angreifer, der ein öffentliches Repository beobachtet, braucht nur den Moment zwischen Push und Bereinigung.

Der eigentliche Fehler liegt nicht darin, dass ein Secret sichtbar wurde. Der Fehler liegt darin, dass die Sichtbarkeit die einzige Kennzahl war, die jemand geprüft hat.

Rotation ist ein Lebenszyklus, kein Einmal-Task

Ein Secret hat einen Anfang, die Ausgabe, eine Nutzungsphase und ein Ende, den Widerruf oder Ablauf. Ein Rotationsprozess macht dieses Ende planbar, statt es einem Vorfall zu überlassen. Dazu gehören mindestens drei Fragen, die für jedes Secret beantwortet sein sollten: Wie lange ist es gültig, bevor es automatisch abläuft? Wer ist zuständig, wenn ein Ablauf ansteht? Und was passiert, wenn ein Secret außerplanmäßig ersetzt werden muss, etwa nach einem Fund im Scan?

Ohne Antworten auf diese drei Fragen bleibt Rotation eine gute Absicht. Mit ihnen wird sie ein Prozessschritt, der genauso zur Pipeline gehört wie der Scan selbst.

Warum Rotation trotzdem meist fehlt

Ein Scanner lässt sich einmal einrichten und läuft danach automatisch mit. Rotation braucht dagegen für jedes einzelne Secret eine Entscheidung: welcher Dienst stellt es aus, wie wird es dort ersetzt, was hängt technisch daran, wenn sich der Wert ändert. Das ist Arbeit, die sich nicht durch ein einzelnes Tool erledigen lässt, sondern ein Inventar voraussetzt: welche Secrets existieren überhaupt, wo werden sie genutzt, und wann wurden sie zuletzt ausgetauscht. Genau dieses Inventar fehlt in den meisten Pipelines, und ohne Inventar lässt sich kein Rotationsplan bauen, sondern nur eine reaktive Notfallmaßnahme nach dem nächsten Fund.

Wo du ansetzen kannst

Rotation lässt sich nicht nachrüsten, indem man den Scanner schärfer stellt. Sie braucht ein Inventar der ausgegebenen Secrets, ein Ablaufdatum pro Secret und eine klare Zuständigkeit dafür, wer den Austausch auslöst. Erst wenn diese drei Elemente stehen, wird aus einem Scan-Ergebnis eine geschlossene Kette: Fund, Bewertung, Austausch, Bestätigung.

Wie ein Rotationsprozess für Zugänge und Geheimnisse technisch eingeführt wird, ist eine Implementierungsfrage, genau wie die Frage, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen, oder wem ein System nach dem Go-Live eigentlich gehört und woran man merkt, dass es niemandem mehr gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Fragen dazu: mm@mhm-dl.de.