In den meisten Pipelines liegt irgendwo ein Deploy-Key oder ein Access-Token, das seit Jahren unverändert ist. Es funktioniert, also fasst es niemand an. Genau das ist das Problem. Ein statisches Secret, das nie rotiert wird, sammelt über die Zeit stillschweigend Risiko an, ohne dass jemand es merkt. Dieser Beitrag zeigt, warum Rotation kein Sicherheits-Luxus ist, sondern eine Grundhygiene, und wie ein realistischer Rotationsprozess aussieht.

Warum ein statisches Secret mit der Zeit gefährlicher wird

Ein Deploy-Key, der drei Jahre alt ist, hat drei Jahre lang Gelegenheit gehabt, zu lecken. Er stand vielleicht kurz in einem Log, wurde in eine alte CI-Konfiguration kopiert, landete im Backup eines Entwickler-Laptops oder wurde einem Dienstleister genannt, der längst nicht mehr im Projekt ist. Keiner dieser Vorfälle löst einen Alarm aus. Das Secret bleibt gültig, und mit jedem Monat wächst die Zahl der Stellen, an denen eine Kopie liegen könnte.

Rotation begrenzt dieses Zeitfenster. Wenn ein Key nach 90 Tagen ausläuft, ist eine Kopie, die vor einem Jahr abgeflossen ist, längst wertlos. Der Schaden eines Lecks hängt weniger davon ab, ob es passiert, sondern wie lange das kompromittierte Secret danach noch gültig ist.

Der beste statische Key ist gar keiner

Bevor man Rotation aufsetzt, lohnt die Frage, ob das Secret überhaupt existieren muss. Für Deployments in Cloud-Umgebungen ersetzt kurzlebige Authentifizierung über OIDC den gespeicherten Key komplett. GitHub Actions oder GitLab tauschen dabei ein Laufzeit-Token gegen kurzlebige Cloud-Credentials, die nach wenigen Minuten verfallen. Es gibt kein statisches Geheimnis mehr, das rotiert werden müsste, weil es keins mehr gibt.

Nicht jeder Fall lässt sich so lösen. Registry-Zugänge, Datenbank-Credentials oder Keys für Dritt-APIs bleiben oft statisch. Für diese gilt: Rotation ist die Pflicht, kurzlebige Tokens sind die Kür.

Was ein Rotationsprozess braucht, um zu funktionieren

Rotation scheitert selten an der Technik, sondern daran, dass niemand weiß, wo alle Kopien eines Keys stecken. Ein Prozess, der trägt, hat drei Bestandteile.

  • Ein Inventar. Jedes langlebige Secret braucht einen Eintrag: wo es liegt, wofür es gilt, wann es zuletzt rotiert wurde. Ohne diese Liste ist jede Rotation ein Ratespiel.
  • Überlappende Gültigkeit. Der neue Key wird erzeugt und ausgerollt, bevor der alte deaktiviert wird. So bricht kein laufender Deploy ab. Erst wenn alle Systeme den neuen Key nutzen, wird der alte gesperrt.
  • Ein fester Takt. Rotation, die nur nach einem Vorfall passiert, passiert zu selten. Ein Intervall von 60 bis 90 Tagen, im Kalender verankert oder automatisiert, macht aus der Ausnahme eine Routine.

Automatisieren, sonst verfällt der Prozess

Ein manueller Rotationsplan hält genau so lange, wie die Person im Team bleibt, die ihn im Kopf hat. Secret-Manager wie HashiCorp Vault, AWS Secrets Manager oder der Google Secret Manager können Keys automatisch erneuern und die neue Version an die verbrauchenden Systeme ausliefern. Der Wert liegt nicht nur in der Bequemlichkeit, sondern darin, dass Rotation stattfindet, auch wenn gerade niemand daran denkt.

Wo das zu groß ist, reicht als erster Schritt ein Ablaufdatum. Ein Key, der technisch nach 90 Tagen verfällt, erzwingt die Rotation von selbst. Der erste fehlgeschlagene Deploy ist unangenehm, aber er ist ein ehrliches Signal, dass der Prozess noch nicht sitzt.

Der erste Schritt: einmal alles anschauen

Bevor man über Intervalle und Tooling nachdenkt, hilft eine simple Bestandsaufnahme. Welche Secrets liegen in den Pipelines, wie alt sind sie, und welche davon könnten durch OIDC ersetzt werden. Oft zeigt schon diese Liste, dass die Hälfte der Keys gar nicht mehr gebraucht wird.

Rotation begrenzt, wie lange ein Zugang gilt. Sie sagt nichts darüber, wie weit er reicht. Ein frisch rotierter Key, der in Staging und Produktion dasselbe darf, ist immer noch ein Generalschlüssel. Wie die zweite Hälfte aussieht, steht in Deploy-Umgebungen trennen.


Der GitSecOps QuickCheck nimmt genau diese Bestandsaufnahme ab. Wir schauen uns an, welche Secrets in euren Pipelines liegen, wie sie verwaltet werden und wo Rotation oder kurzlebige Tokens sinnvoll sind. Ergebnis nach drei Werktagen, Festpreis 1.990 Euro netto. Kontakt: mm@crank.zone.

MHM Digitale Lösungen

Wir machen Software-Lieferketten sicher. GitSecOps prüft und härtet deine Build- und Deployment-Pipeline, damit du gegenüber Kunden und Prüfern bestehst. Hier schreiben wir nüchtern über Supply Chain Security, DevSecOps und digitales Business.

Kontakt