GitLab selbst betreiben: So sichern KMU ihren Code-Server richtig ab

Viele Softwarehäuser, Agenturen und Maschinenbauer mit eigener Entwicklungsabteilung betreiben GitLab auf dem eigenen Server – aus Datenschutzgründen, wegen der Kosten oder weil der Quellcode das Haus nicht verlassen soll. Das ist nachvollziehbar, macht das Unternehmen aber selbst für die Sicherheit verantwortlich. Die jüngsten Updates zeigen, wie schnell ein selbst gehostetes GitLab zum Einfallstor werden kann, wenn Patches liegen bleiben.

Was bei GitLab aktuell passiert ist

Wie heise online am 25. September 2026 berichtete, hat GitLab Sicherheitsupdates für die Community und die Enterprise Edition veröffentlicht. Abgesichert sind die Versionen 19.4.1, 19.3.3 und 19.2.7. Die wichtigsten Punkte:

• Zwei kritische Lücken in der Verarbeitung regulärer Ausdrücke: Über präparierte Regex-Muster in CI/CD-Konfigurationen können angemeldete Nutzer beliebigen Code auf dem GitLab-Server ausführen.
• Zwei Lücken mit hohem Risiko: eine Cross-Site-Scripting-Schwachstelle in den Diff-Ansichten von Merge Requests sowie – nur in der Enterprise Edition – ein unberechtigter Zugriff auf CI/CD-Variablen.
• Sieben weitere Schwachstellen mit geringerem Schweregrad betreffen Berechtigungen, Zugriff auf Inhalte und CI/CD-Job-Logs.

GitLab.com und GitLab Dedicated sind bereits aktualisiert. Wer GitLab selbst betreibt (Self-Managed), muss selbst handeln. Aktive Angriffe waren zum Zeitpunkt der Meldung nicht bekannt – das ändert sich erfahrungsgemäß schnell, sobald Details zu den Lücken öffentlich sind.

Warum ein GitLab-Server ein lohnendes Ziel ist

Quellcode ist Geschäftsgeheimnis

Im Repository liegt oft das Kernprodukt eines Unternehmens: Firmware, Steuerungssoftware, Kundenprojekte. Für ostdeutsche KMU aus Elektronik, Automatisierung oder Softwareentwicklung ist der Quellcode häufig wertvoller als jede Kundendatenbank.

Secrets in CI/CD-Variablen

Build-Pipelines brauchen Zugänge: Deploy-Schlüssel für Produktivserver, Cloud-Zugangsdaten, Signaturzertifikate, API-Token. Diese liegen typischerweise als CI/CD-Variablen in GitLab. Wer den Server übernimmt oder unberechtigt Variablen ausliest – genau das ermöglichte eine der aktuellen Lücken – erhält oft Zugang zu weiteren Systemen. Mehr dazu in unserem Beitrag zum Schutz von API-Schlüsseln.

Ausgangspunkt für Lieferkettenangriffe

Wer Code oder Pipelines manipulieren kann, schleust Schadcode in Software ein, die an Kunden ausgeliefert wird. Das Muster kennen wir aus Angriffen auf Artifact-Repositories und andere DevOps-Tools.

„Nur angemeldete Nutzer” ist kein Trost

Die kritischen Lücken setzen einen Login voraus. In der Praxis haben aber oft Werkstudenten, externe Freelancer oder Kundenkonten Zugriff – und gestohlene Zugangsdaten aus Infostealern sind billig zu haben. Ein einziges kompromittiertes Konto mit Pipeline-Rechten genügt.

Praxis: GitLab Self-Hosted in 7 Schritten absichern

1. Sofort aktualisieren

Prüfen Sie unter Admin → Übersicht die laufende Version und aktualisieren Sie auf 19.4.1, 19.3.3 oder 19.2.7 – je nach genutztem Release-Zweig. Bei Omnibus-Installationen auf Debian oder Ubuntu erledigt das der Paketmanager, bei Docker-Setups ein neues Image. Vorher ein Backup ziehen (gitlab-backup create) und die Konfigurationsdateien gitlab.rb sowie gitlab-secrets.json separat sichern – ohne letztere ist ein Restore wertlos.

2. Updates zur Routine machen

GitLab veröffentlicht planmäßig zweimal im Monat Patch-Releases, oft mit Sicherheitsfixes. Abonnieren Sie die Security-Release-Hinweise und planen Sie feste Wartungsfenster. Wie das strukturiert funktioniert, beschreibt unser Artikel zum Patch-Management für KMU.

3. Nicht offen ins Internet stellen

Ein GitLab, das nur intern genutzt wird, braucht keine öffentliche Erreichbarkeit. Setzen Sie die Instanz hinter die Firewall und binden Sie externe Entwickler per WireGuard-VPN an. Wenn eine öffentliche Erreichbarkeit nötig ist: Registrierung deaktivieren, Anmeldung nur mit Zwei-Faktor-Authentifizierung erzwingen und Admin-Bereiche zusätzlich einschränken.

4. Benutzer und Rechte aufräumen

• Öffentliche Selbstregistrierung abschalten.
• Inaktive Konten und ehemalige Mitarbeitende regelmäßig sperren.
• Rollen nach dem Minimalprinzip vergeben: Nicht jeder braucht Maintainer-Rechte.
• Personal Access Tokens mit Ablaufdatum versehen und Altbestände widerrufen.
• Anmeldung möglichst über zentrales Single Sign-On koppeln, damit das Offboarding an einer Stelle greift.

5. Runner isolieren

GitLab Runner führen beliebigen Code aus den Repositories aus. Sie sollten deshalb nie auf dem GitLab-Server selbst laufen. Nutzen Sie separate VMs oder Container, vermeiden Sie den Docker-Executor im privilegierten Modus und trennen Sie Runner für Produktiv-Deployments von Runnern für allgemeine Builds.

6. Secrets richtig schützen

CI/CD-Variablen als masked und protected markieren, damit sie nicht in Job-Logs erscheinen und nur auf geschützten Branches verfügbar sind. Deploy-Schlüssel pro Projekt und Umgebung trennen. Nach einem Sicherheitsvorfall gilt: Alle in GitLab hinterlegten Zugangsdaten rotieren.

7. Betrieb überwachen und Backups prüfen

Leiten Sie die GitLab-Logs (insbesondere Audit-Events und Anmeldungen) in ein zentrales Monitoring. Auffällige Pipeline-Änderungen oder neue Admin-Konten sollten einen Alarm auslösen. Und: Testen Sie die Wiederherstellung regelmäßig, am besten aus unveränderlichen Backups, damit ein Angreifer nicht auch die Sicherung löscht.

Selbst betreiben oder GitLab.com nutzen?

Die Entscheidung hängt vom Einzelfall ab. Das selbst gehostete GitLab bietet volle Datenhoheit – interessant für Unternehmen mit Geheimhaltungsvereinbarungen, Rüstungs- oder Medizintechnikbezug. Dafür braucht es jemanden, der Updates, Backups und Härtung verlässlich übernimmt. Wer das intern nicht leisten kann, fährt mit einer gehosteten Variante oder einem externen Betreuer oft sicherer als mit einem vergessenen Server im Keller. Für viele KMU in Sachsen ist ein Mittelweg sinnvoll: eigener Server im deutschen Rechenzentrum, Betrieb und Patches durch einen Dienstleister.

Sie suchen Unterstützung in Dresden?

Rexoma hilft KMU in Dresden und ganz Sachsen dabei, selbst gehostete Entwicklerwerkzeuge wie GitLab sicher zu betreiben: von der Härtung des Linux-Servers über die Anbindung per WireGuard-VPN bis zu isolierten Runnern und einem verlässlichen Update-Prozess. Wir prüfen Ihre bestehende Instanz und zeigen, wo Handlungsbedarf besteht. Nehmen Sie Kontakt mit uns auf – wir sind Ihr Ansprechpartner für Linux-Server und IT-Sicherheit in Dresden.

FAQ: GitLab Self-Hosted absichern

Bin ich von den aktuellen GitLab-Lücken betroffen?

Betroffen sind selbst betriebene Installationen der Community und Enterprise Edition vor den Versionen 19.4.1, 19.3.3 bzw. 19.2.7. GitLab.com und GitLab Dedicated wurden vom Hersteller bereits aktualisiert.

Reicht es, wenn mein GitLab nur im internen Netz erreichbar ist?

Es senkt das Risiko deutlich, ersetzt aber keine Updates. Die kritischen Lücken sind für angemeldete Nutzer ausnutzbar – also auch für ein kompromittiertes Mitarbeiterkonto oder einen infizierten Entwicklerrechner im eigenen Netz.

Wie oft sollte ich GitLab aktualisieren?

GitLab veröffentlicht regelmäßig Patch-Releases, meist zweimal im Monat. Sicherheitsupdates sollten innerhalb weniger Tage eingespielt werden, kritische Fixes möglichst sofort.

Dürfen GitLab Runner auf demselben Server laufen?

Technisch möglich, aber nicht empfehlenswert. Runner führen Code aus Repositories aus. Laufen sie auf dem GitLab-Server, kann ein manipulierter Build direkt die Instanz und alle gespeicherten Secrets gefährden.

Was muss ich nach einem Verdacht auf Kompromittierung tun?

Instanz vom Netz trennen, Logs sichern, alle Tokens, Deploy-Schlüssel und CI/CD-Variablen rotieren und die Integrität der Repositories prüfen. Ziehen Sie frühzeitig einen Dienstleister für Incident Response hinzu.