Bildquelle: Bildquelle: Pexels / Jakub Zerdzicki / https://www.pexels.com/photo/secure-office-locker-with-key-in-lock-29940222/
Geheime Variablen reichen nicht mehr für Plattformteams mit geteilten Pipelines
GitLab 19.0 bringt mit dem Secrets Manager eine Funktion in den Vordergrund, die im DevOps-Alltag schnell unterschätzt wird. Auf den ersten Blick wirkt das wie eine weitere Produktmeldung über sicherere Geheimnisse in CI/CD. Interessant ist aber etwas anderes: GitLab beschreibt sehr offen den eigentlichen Betriebsfehler vieler Teams. Zugangsdaten landen nicht deshalb in der falschen Form in Pipelines, weil niemand das Risiko kennt. Sie landen dort, weil das bisher verfügbare Modell im Alltag zu grob, zu bequem oder zu umständlich zugleich ist. Genau deshalb ist der neue Secrets-Manager-Ansatz nicht bloß ein Security-Detail, sondern eine Betriebsfrage für Plattformteams, die mit gemeinsamen Templates, Runnern und Projektgrenzen arbeiten.
Für Leser ohne tiefen DevSecOps-Hintergrund: Ein Secrets Manager verwaltet vertrauliche Werte wie API-Schlüssel, Datenbank-Passwörter oder Zertifikate, die in Deployments, Builds oder Tests benötigt werden. Statt diese Werte als normale CI/CD-Variablen oder in Dateien herumliegen zu lassen, werden sie gezielt nur dann und nur dort bereitgestellt, wo ein Job sie wirklich braucht. Das ist wichtig, weil kompromittierte Build-Pipelines sonst schnell zum Einfallstor für größere Folgeschäden werden.
GitLab adressiert einen alten Bequemlichkeitsfehler
Im offiziellen Blog zum Start des Public Beta am 21. Mai 2026 benennt GitLab das Kernproblem ungewöhnlich klar. Geheimnisse landen oft in übermäßig weit gefassten CI/CD-Variablen, in Konfigurationsdateien oder im berüchtigten temporären .env, das angeblich nur kurz gebraucht wird. Diese Improvisation entsteht nicht zufällig. Sie ist das Ergebnis eines Arbeitsalltags, in dem Teams schnelle Lieferfähigkeit höher gewichten als saubere Reichweitenbegrenzung.
Genau hier setzt GitLab an. Laut Release-Kommunikation und Produktdokumentation werden Secrets im neuen Modell nicht einfach auf Projekt- oder Gruppenebene abgelegt und dann breit in Jobs injiziert. Stattdessen lassen sie sich an Branches, Umgebungen und Schutzstatus koppeln. Entscheidend ist nicht nur, wo ein Secret gespeichert wird, sondern unter welchen Job-Bedingungen es überhaupt ausgegeben werden darf. Das ist operativ ein spürbarer Unterschied. Wer ein Deployment nur auf geschützten Branches und nur in einer Produktionsumgebung zulässt, kann dieselbe Logik jetzt enger mit dem Credential-Zugriff verbinden.
GitLab beschreibt zusätzlich, dass Geheimnisse standardmäßig als temporäre Datei in den Job gegeben werden, deren Pfad dann als Umgebungsvariable dient. Das klingt klein, ist aber relevant. In vielen Nebenpfaden von Build-Jobs, Subprozessen, Crash-Dumps oder Telemetrie ist ein Dateipfad weniger exponiert als der rohe Secret-Wert selbst. Auch das ist keine perfekte Magie, aber ein vernünftiger Schritt weg von breit streuenden Variablenmustern.
Der eigentliche Nutzen liegt in weniger Parallelwelten
Der stärkste Punkt an GitLabs Darstellung ist aus meiner Sicht nicht die reine Secret-Ablage. Spannend ist die Frage, was Plattformteams nicht mehr parallel pflegen müssen. Der Blog und die Dokumentation betonen, dass GitLab den vorhandenen Gruppen- und Projektkontext als Berechtigungsrahmen nutzt. Damit entfällt zumindest für bestimmte Fälle das zweite Zugriffsmodell, das in separaten Vault-Lösungen gepflegt und synchronisiert werden muss.
Das bedeutet nicht, dass externe Secret Stores plötzlich überflüssig wären. GitLab sagt selbst, dass Integrationen mit HashiCorp Vault, AWS Secrets Manager, Azure Key Vault und Google Cloud Secret Manager weiter bestehen. Für große Organisationen mit zentralen Sicherheitsvorgaben, Hardware-Backends oder cloudübergreifender Schlüsselpolitik bleibt das wichtig. Aber für viele Plattform- und Produktteams ist die eigentliche Alltagshürde eine andere: Sie verlieren Zeit an Berechtigungsdrift zwischen Codeplattform, CI-System und separatem Secret-Tool. Wenn Rollenwechsel, Teamaustritte oder neue Projekte in zwei Modellen gleichzeitig sauber nachgezogen werden müssen, wächst das Risiko nicht trotz Governance, sondern mitten in ihr.
GitLab versucht diesen Bruch zu verkleinern. Der Secrets Manager nutzt dieselben Projekt- und Gruppenstrukturen, die Teams ohnehin für Code, Pipelines und Ownership pflegen. Wird jemand aus einem Projekt entfernt, verliert die Person laut GitLab unmittelbar auch den Zugriff auf die zugehörigen Secrets. Für Plattformteams mit vielen geteilten Templates und wechselnden Teams ist das vor allem organisatorisch interessant. Sicherheit steigt hier nicht nur durch mehr Technik, sondern durch weniger Modellbruch.
Least Privilege wird in Pipelines erst glaubwürdig, wenn Jobs ihr Secret wirklich anfordern müssen
Besonders relevant ist der Blick auf geteilte Pipelines. In vielen Organisationen konsumieren Hunderte Projekte dieselben Includes, Runner-Standards oder Deployment-Bausteine. Genau dort entstehen oft zu breite Variablenmodelle. Ein Secret liegt auf Gruppenebene, mehrere Jobs könnten es theoretisch lesen, und niemand prüft später noch sauber, welcher Pfad es tatsächlich gebraucht hätte. Im Ernstfall wird dann nicht nur ein Deployment-Zugang rotiert, sondern eine ganze Zone des Betriebs in hektische Reparatur versetzt.
GitLab argumentiert hier mit der kleineren Blast Radius. Wird ein Credential kompromittiert, soll sich nachvollziehen lassen, welcher Job es verwendet hat und unter welchen Bedingungen es zugänglich war. Die Dokumentation ergänzt dazu einen wichtigen operativen Punkt: Secret-Reads aus CI/CD-Pipelines laufen als Audit-Ereignisse mit Pipeline- und Job-IDs mit. Genau diese Verbindung ist in realen Incidents Gold wert. Denn die unangenehmste Arbeit nach einem Leak beginnt oft nicht bei der Rotation, sondern bei der Rekonstruktion, welche Jobs, Branches oder Umgebungen überhaupt betroffen waren.
Für Plattform- und Security-Leitungen ist das die eigentliche Botschaft von GitLab 19.0. Geheimnisse werden nicht erst sicherer, wenn man irgendwo einen neuen Tresor einschaltet. Sie werden erst dann glaubwürdiger verwaltet, wenn Pipelines ihren Bedarf explizit anmelden müssen und dieser Bedarf an echte Laufbedingungen gekoppelt ist. Das ist im Kern eine Rückkehr zu Least Privilege, aber in einer Form, die besser in den CI-Betrieb passt als die alte Alles-oder-Nichts-Variable.
Was Teams jetzt praktisch prüfen sollten
Der erste sinnvolle Prüfschritt ist nüchtern: Welche Secrets liegen heute noch als klassische CI/CD-Variablen in Gruppen oder Projekten, obwohl sie nur in einem kleinen Teil der Jobs gebraucht werden? Schon diese Bestandsaufnahme zeigt meist, wie stark Bequemlichkeit das Modell bisher geprägt hat.
Der zweite Schritt betrifft die Struktur der Pipelines. Wenn Branch-Schutz, Umgebungsnamen oder Deployment-Pfade im Unternehmen unsauber definiert sind, wird auch ein moderner Secrets Manager nur begrenzt helfen. GitLabs Ansatz lebt davon, dass Branches, Environments und Protected States wirklich tragfähige Steuergrößen sind. Wer dort Chaos hat, automatisiert sonst nur eine unsaubere Wirklichkeit.
Der dritte Schritt ist die Entscheidung über die Zielarchitektur. Für manche Teams wird GitLab Secrets Manager als nativer Standard für projektnahe Build- und Deployment-Secrets reichen. Für andere bleibt er eher die operative Ergänzung zu einem zentralen Vault-Modell. Beides kann sinnvoll sein. Wichtig ist nur, dass die Auswahl aus Betriebslogik erfolgt und nicht aus alter Gewohnheit. Wenn Teams weiterhin jedes Secret als globale Variable verteilen, obwohl feinere Steuerung vorhanden ist, liegt das Problem nicht mehr an fehlender Technik, sondern an fehlender Disziplin.
Unterm Strich ist GitLab 19.0 beim Secrets Manager interessanter als die typische Release-Rhetorik vermuten lässt. Nicht weil jetzt plötzlich jedes Secret-Problem gelöst wäre. Sondern weil GitLab einen realen Engpass im Delivery-Alltag angreift: zu breite Reichweiten, doppelte Berechtigungsmodelle und zu wenig nachvollziehbare Secret-Nutzung in geteilten Pipelines. Gerade für Plattformteams ist das keine Randnotiz, sondern ein brauchbarer Anlass, das eigene CI-Sicherheitsmodell härter zu hinterfragen.
