GitLab ist laengst nicht mehr nur Git. Es speichert Source Code, fuehrt Tests aus, baut Container, veroeffentlicht Artefakte, deployed Kubernetes-Workloads und fuettert Compliance-Dashboards.

Damit wird GitLab zu einem der wertvollsten Systeme in einer modernen Engineering-Organisation. Gleichzeitig wird es zu einem sehr attraktiven Ziel.

In 2026 bedeutet GitLab-Hardening nicht nur, Patches einzuspielen. Patches sind wichtig, aber sie schuetzen keine falsch konfigurierte Instanz, keinen ueberprivilegierten Runner, keine geleakte CI-Variable und keine zu offene Gruppenrichtlinie.

Ein paar aktuelle Signale sind wichtig:

• GitLab 19.0 wurde am 21. Mai 2026 veroeffentlicht.
• GitLab 19.1 ist fuer den 18. Juni 2026 geplant.
• GitLab 19.0 erweitert Secrets Management, CI-Sichtbarkeit und Supply-Chain-Kontrollen.

Die Aussage ist einfach: GitLab bekommt immer mehr Security-Funktionen, aber die Umgebung ist nur so sicher wie ihre Konfiguration und ihr Betrieb.

Die wertvollsten GitLab-Assets

Bevor man etwas haertet, muss klar sein, was geschuetzt wird.

Die wertvollsten GitLab-Assets sind meistens:

• Source Code: geistiges Eigentum, Business-Logik, interne Tools, Produkt-Roadmap.
• Secrets: Cloud Tokens, SSH Keys, CI Variables, Deploy Keys, Vault Credentials, Build Logs.
• Container und Artefakte: signierte Builds, Package Outputs, Docker Layers, Helm Charts.
• CI-Infrastruktur: Runners, Kubernetes-Cluster, Registry-Zugriff, Release Jobs, Deployment-Umgebungen.
• Compliance-Nachweise: Audit Logs, Approval History, Vulnerability Reports, Merge-Request-Daten.

Wenn ein Angreifer GitLab erreicht, muss er Produktion nicht direkt kompromittieren. Er kann stattdessen die Software Supply Chain vergiften.

Eine Geschichte aus der Praxis

Ein Fintech-Team behandelte ein privates Repository als "sicher genug", weil es nur innerhalb des Office-Netzwerks sichtbar war.

Ein Praktikant pushte waehrend einer Migration einen Cloud Key in dieses Repository. Innerhalb weniger Minuten fanden automatisierte Scanner das Credential. Cloud Functions begannen Crypto Mining, und die Monatsrechnung stieg um Zehntausende Dollar.

Der schmerzhafte Teil war nicht der Fehler. Menschen machen Fehler.

Der schmerzhafte Teil war, dass das System davon ausging, dass Menschen nie Fehler machen. Secret Scanning, kurzlebige Credentials, Least Privilege und automatische Key Revocation haetten das frueher abfangen sollen.

Typische Ziele von Angreifern

Angreifer wollen meist eines von vier Dingen:

• Ransom: Repositories verschluesseln oder Zugriff blockieren und Zahlung verlangen.
• Supply-Chain Injection: Library, Image, Release Script oder Deployment-Artefakt manipulieren.
• Zertifikats- und Signing-Key-Diebstahl: Malicious Builds mit vertrauenswuerdiger Firmenidentitaet signieren.
• Insider Sabotage: Release Tags loeschen, .gitlab-ci.yml brechen, Checks deaktivieren oder Artefakte vor Launch vergiften.

Die meisten dieser Angriffe brauchen kein Hollywood-Hacking. Sie leben von schwachen Defaults, alten Versionen, breiten Rechten und Secrets am falschen Ort.

Die Zwei-Spuren-Verteidigung

Ich teile GitLab Security gern in zwei Spuren.

Reactive Actions stoppen aktuelles Bluten:

• verwundbare Versionen patchen,
• geleakte Secrets rotieren,
• riskante Tokens deaktivieren,
• Runners sperren,
• auffaellige Pipelines pruefen,
• Accounts und Sessions widerrufen.

Proactive Changes erhoehen den Preis jedes zukuenftigen Angriffs:

• private-by-default Projekte,
• klare Rollen-Grenzen,
• kurzlebige Access Tokens,
• signierte Commits und geschuetzte Tags,
• Secret Scanning,
• immutable Logs,
• isolierte Runners,
• negative Security Tests in CI.

Man braucht beides. Reaktive Arbeit begrenzt Incidents. Proaktive Arbeit reduziert, wie oft Incidents passieren.

CVE-2023-7028: Account Hijack ueber Password Reset

Das Password-Reset-Problem CVE-2023-7028 betraf GitLab-Versionen, in denen ein Angreifer Reset-E-Mail-Verhalten manipulieren und Password-Reset-Links an unerwuenschte Adressen senden konnte.

Reaktive Schritte

Beginne mit sofortigen Kontrollen:

• Zwei-Faktor-Authentifizierung fuer Admins, Owners und Maintainers erzwingen,
• Password-Reset-Aktivitaet pruefen,
• gitlab-rails/production_json.log auf ungewoehnliche E-Mail-Arrays untersuchen,
• SMTP so beschraenken, dass Password-Reset-Mails nur von genehmigten Firmen-Domains kommen,
• Credentials fuer auffaellige Accounts rotieren.

Proaktive Schritte

Danach zukuenftige Exponierung reduzieren:

• auf eine aktuell unterstuetzte GitLab-Linie upgraden,
• Alerts auf Spikes in PasswordsController#create setzen,
• Usernames von E-Mail-Adressen trennen,
• public user enumeration deaktivieren, wo es moeglich ist,
• SSO und SCIM fuer Enterprise Identity Lifecycle nutzen.

Die Lektion ist groesser als diese eine CVE: Identity-Flows verdienen dasselbe Monitoring wie Deployment-Flows.

CVE-2024-6385: Pipelines als anderer User ausfuehren

CVE-2024-6385 zeigte, wie gefaehrlich CI-Impersonation werden kann. Wenn ein Angreifer eine Pipeline als jemand anderes starten kann, erbt er moeglicherweise Zugriff auf Variablen, protected branches, Deployment Jobs oder Release Workflows.

Reaktive Schritte

Suche nach Pipeline-Verhalten, das nicht zur normalen Aktivitaet passt:

• ungewoehnliche Branches,
• unerwartete User,
• Jobs auf protected runners,
• Deployments ausserhalb normaler Zeitfenster,
• Artefakte aus verdaechtigen Commits.

Danach Runner-Zugriff einengen:

• shared runners sperren,
• protected runners fuer protected branches nutzen,
• Jobs sauber taggen,
• breite runner registration tokens vermeiden,
• veraltete project runners entfernen.

Proaktive Schritte

Langfristig muss Pipeline-Identitaet sichtbar werden:

• Pipeline Logs in immutable Storage schicken,
• ueberwachen, wer jedes Deployment ausgeloest hat,
• Approvals fuer protected environments verlangen,
• personal access tokens kurzlebig halten,
• vor Token-Ablauf warnen, damit niemand unsichere Workarounds baut.

CI/CD-Identitaet ist Produktionsidentitaet. Behandle sie so.

Vier menschliche Schwachstellen und praktische Fixes

Viele GitLab-Incidents beginnen mit normalen menschlichen Fehlern. Das Ziel ist nicht, Menschen zu beschuldigen. Das Ziel ist, sicheres Verhalten einfacher zu machen als unsicheres Verhalten.

1. Secrets im Code

Beispiel: Ein Entwickler hardcodiert ein Datenbankpasswort in einem Migration Script.

Fix:

• Vault, GitLab Secrets Manager oder einen Cloud Secret Manager verwenden,
• Secret Scanning in Merge Requests aktivieren,
• geleakte Credentials sofort rotieren,
• History mit git filter-repo bereinigen, wenn der Leak bereits committed wurde,
• Pushes mit high-confidence Secrets blockieren.

Verlasse dich nicht nur auf "bitte keine Secrets committen". Automation ist freundlicher und zuverlaessiger.

2. Unsigned Commits

Beispiel: Ein Angreifer pusht Code ueber einen kompromittierten Account oder eine Bot-Identitaet.

Fix:

• GPG- oder SSH-signierte Commits verlangen,
• unsigned commits auf Gruppenebene ablehnen,
• Release Branches schuetzen,
• Tags schuetzen, die fuer Deployments genutzt werden,
• Merge-Request-Approvals fuer Production Paths verlangen.

Signing loest nicht jedes Problem, erhoeht aber das Vertrauensniveau der Change History.

3. Oeffentliches .git-Verzeichnis

Beispiel: Ein falsch konfigurierter Webserver exponiert /.git/, und ein Tester laedt das Repository herunter.

Fix in Nginx:

location ~ /\.git {
  deny all;
}

Auch CDN Caches und Object Storage Buckets pruefen. Ein blockierter Origin reicht nicht, wenn das Repository woanders gecached wurde.

4. Unlimited Shared Runners

Beispiel: Ein Contractor startet einen Stress Test, und Autoscaling erzeugt ueber Nacht Hunderte teure Cloud-Instanzen.

Fix:

• CI-Minute-Quotas setzen,
• kritische Projekte isolieren,
• Jobs streng taggen,
• Runner Scope begrenzen,
• Cloud Budget Alerts setzen,
• Approval vor teuren Jobs verlangen.

Runners sind Compute-Infrastruktur. Behandle sie wie Produktionskapazitaet, nicht wie kostenlose Hintergrundmechanik.

Sechs Gewohnheiten eines gesunden GitLab-Clusters

Ein gesunder GitLab-Cluster hat meistens diese Gewohnheiten:

• Private by default: Projekte, Gruppen, Snippets und Packages sind geschlossen, sofern sie nicht explizit geoeffnet werden.
• Patch-Rhythmus: GitLab released monatlich und haeufig Patch Releases; Updates vor Produktion testen.
• Infrastructure as Code: gitlab.rb, Helm Values, Terraform und Ansible in Git mit Review halten.
• Scanning ueberall: Dependency Scanning, SAST, Container Scanning, IaC Scanning und Secret Scanning laufen auf Merge Requests.
• Quarterly Role Audits: temporaere Rechte nach jedem Release Cycle entfernen.
• Negative Security Tests: CI failt, wenn jemand ein Secret pusht, /.git/ exponiert oder Required Checks umgeht.

Der letzte Punkt wird unterschaetzt. Security-Regeln sollten ausfuehrbar sein. Wenn eine Regel wichtig ist, sollte CI sie testen.

Hardening in Business-Prozesse einbetten

GitLab-Hardening funktioniert am besten, wenn es Teil des Business-Prozesses ist und keine Nebenaufgabe.

Starte mit den Incidents, die das Business nicht tolerieren kann:

• geleakte Kundendaten,
• Produktionsausfall zur Peak-Zeit,
• malicious Release Artifact,
• kompromittierter Signing Key,
• Cloud-Kostenexplosion,
• Compliance-Audit-Failure.

Danach Controls auf diese Risiken mappen.

Nuetzliche Operating Habits:

• einen Owner fuer security-sensitive Merge Requests benennen,
• GitLab-Patches durch denselben RFC-, Test- und Rollout-Flow schicken wie Produkt-Aenderungen,
• kurze monatliche Security-Learning-Sessions halten,
• neue Policies vor Enforcement auf SLA-Impact mappen,
• Break-Glass-Zugriff dokumentieren und auditieren,
• Credential Rotation ueben, bevor der echte Incident kommt.

Culture ist guenstiger als Breaches, aber Culture braucht Automation, um unter Druck zu halten.

Fazit

Keine GitLab-Umgebung ist unverwundbar. Die eigentliche Mission ist, jeden Exploit teuer, laut und kurzlebig zu machen.

In 2026 sind die drei Saeulen einer sicheren GitLab-Umgebung:

• regelmaessige Upgrades,
• disziplinierte Secret Hygiene,
• klare Rollen- und Runner-Grenzen.

Fuege signierte Commits, protected tags, immutable logs und negative CI Tests hinzu, und die Aufgabe des Angreifers wird deutlich schwerer.

Das ist das Ziel: keine perfekte Security, sondern eine GitLab-Plattform, in der Fehler frueh erkannt werden, Privilegien eng bleiben und jede verdaechtige Aktion eine Spur hinterlaesst.