Wie VTS mit GitLab Lizenz-Audits um 75 Prozent beschleunigt und Governance stärkt

VTS nutzte GitHub als primäre Quellcode-Plattform, ergänzt durch sechs weitere Drittanbieter-Werkzeuge für Quellcodeverwaltung, Code-Qualität, Schwachstellen-Scanning, CI/CD und Lizenzmanagement. Code-Qualität erforderte SonarQube, Schwachstellen-Scanning weitere separate Werkzeuge, CI/CD-Pipelines einen zusätzlichen externen Dienst. Dieses fragmentierte Setup erhöhte den Verwaltungsaufwand und schuf ein wachsendes Risiko von Konfigurationsabweichungen über Repositories hinweg.

„Ich würde es als lästig, umständlich und fehleranfällig beschreiben", erklärt Jacques Buitendag, Head of Technology. „Teams bekamen GitHub, aber GitHub war nie als Gesamtlösung konzipiert. Für Code-Qualität musste ein weiteres Werkzeug wie SonarQube integriert werden. Für das Schwachstellen-Scanning Tools wie OWASP Dependency-Check. Das ließ Raum für Abweichungen in den Pipelines."

Governance-Anforderungen verlangten klare Antworten: Haben wir die richtigen Prozesse? Führen wir sie konsistent aus? Können wir es nachweisen? Mit über mehrere Anbieter verteilten Werkzeugen wurde die Zusammenstellung von Audit-Berichten zu einer tagelangen Aufgabe.

Die Lizenz-Compliance-Prüfung machte das Problem deutlich: Jährlich prüfte VTS manuell jedes Projekt, extrahierte Abhängigkeiten, konsolidierte Duplikate und verglich sie mit dem Vorjahr. Dieser Prozess beanspruchte zwei volle Arbeitstage.

Sicherheitstransparenz litt unter denselben Einschränkungen. Scans erfolgten auf Repository-Ebene ohne organisationsweiten Überblick, sodass Schwachstellen spät auftauchten – nachdem Teams sich gegenüber Kunden bereits zu Lieferterminen verpflichtet hatten.

VTS entschied sich für GitLab Ultimate mit Self-Hosted-Deployment aus drei Gründen: konsolidierte Governance-Funktionen, Infrastrukturkontrolle und eine nahtlose Entwicklererfahrung.

GitLab bot VTS eine einheitliche Übersicht über alle Projekte und konsolidierte Schwachstellenmanagement, Lizenz-Compliance und Sicherheits-Scanning. Die Teams erhielten einen klaren Audit-Trail und mussten keine separaten Werkzeuge mehr integrieren oder Audit-Daten manuell zusammenstellen.

Das Self-Hosted-Modell erwies sich als entscheidend. VTS musste Worst-Case-Szenarien einplanen. Durch den Betrieb von GitLab auf der eigenen Infrastruktur kann das Team Systeme isolieren, Netzwerkkommunikation unterbrechen und Kunden bei einem Sicherheitsvorfall klar abgegrenzte Zuständigkeitsbereiche nachweisen.

„Im regulierten Umfeld müssen wir immer einen Plan für das Worst-Case-Szenario haben. Mit GitLab Self-Hosting haben wir das. GitLab Self-Hosting gibt uns die volle Kontrolle über den Netzwerkzugang", erklärt Buitendag.

VTS schloss die Migration in drei Monaten ab – einschließlich Infrastrukturaufbau, Backup-Konfiguration und Migration aller Repositories und Pipelines.

Aus Engineering-Sicht war der Übergang bewusst unsichtbar gestaltet. GitLab bot Feature-Parität mit GitHub, der Kernworkflow blieb unverändert – gleiche Branches, Merge Requests, Review-Prozess. Die Teams benötigten keine Umschulung.

„Die Migration verlief sehr reibungslos", sagt Karen Ip, Head of Engineering. „Wir erhielten starke Unterstützung vom GitLab-Team, das unsere technischen Mitarbeitenden beim Infrastrukturaufbau begleitete."

Die Governance-Vorteile zeigten sich unmittelbar. Zuvor verteiltes Sicherheits-Scanning – SAST, DAST, Container-Scanning, Dependency-Scanning, Secret Detection – wurde in GitLabs native Funktionen konsolidiert.

Bei der Lizenz-Compliance-Prüfung zeigte sich der Effizienzgewinn klar: Was zuvor zwei volle Arbeitstage beanspruchte, dauerte jetzt einen halben Tag. Buitendag rief GitLabs Dependency-Ansicht auf, lud die konsolidierte Liste herunter und identifizierte die Änderungen zum Vorjahr.

„Ich habe einen mehrtägigen Prozess buchstäblich auf einen halben Tag reduziert", so Buitendag. „Es war nicht nur schneller – es hat auch die Genauigkeit und Transparenz erhöht."

Die Sicherheit verbesserte sich erheblich. Schwachstellen erscheinen nun direkt in Merge Requests, sodass Teams die Auswirkungen bewerten können, bevor Code gemergt wird. Statt Probleme erst nach eingegangenen Lieferverpflichtungen zu entdecken, können Teams Risiken frühzeitig einschätzen und fundierte Entscheidungen treffen.

„Frühzeitige Transparenz durch Shift-Left ist eine große Hilfe", betont Ip. „Wenn eine Schwachstelle gemeldet wird, können wir die transitive Abhängigkeitskette prüfen: Wird dieser Teil der Abhängigkeit tatsächlich genutzt? Falls nicht, wählen wir die passende Option je nach Art der Schwachstelle – entfernen oder bei niedrigem Risiko beheben, sobald ein Patch verfügbar ist."

Der geschäftliche Nutzen zeigt sich in der Liefersicherheit. Ingenieurinnen und Ingenieure können Kundenterminen mit Zuversicht zusagen, da Sicherheitsprobleme während der Entwicklung sichtbar werden – nicht erst nach eingegangenen Verpflichtungen.

VTS betrachtet die initiale Migration als Phase eins. Das Team plant, mit GitLab automatisch temporäre Umgebungen hochzufahren, vollständige Test-Suiten auszuführen und Änderungen vor dem Merging zu validieren – mit automatisierten Indikatoren bei Problemen. VTS rechnet damit, dass Phase zwei der Migration die Build-Zeit durch GitLabs Konfigurationsflexibilität über die Pipeline-Architektur um bis zu 50 % reduzieren wird.

„Wir untersuchen, wie GitLab unseren Software-Entwicklungslebenszyklus weiter verbessern und optimieren kann", erklärt Ip. „GitLab automatisiert Prozesse, testet in temporären Umgebungen und validiert vor dem Einbinden in den Hauptzweig – das ist wirklich wichtig."