Veröffentlicht am: 9. Juni 2025
5 Minuten Lesezeit
Letztes Jahr haben wir das Secure by Design-Versprechen unterzeichnet – hier ist unser Fortschritt
Erfahre mehr über GitLabs CISA-konforme Erweiterungen und Verbesserungen bei MFA, Reduzierung von Standardpasswörtern, Patches und Offenlegung von Schwachstellen.
Vor etwas mehr als einem Jahr hat GitLab CISAs Secure by Design Pledge unterzeichnet, eine Richtlinie für Technologieanbieter, Sicherheit von Beginn der Entwicklung an ins Herz ihrer Produkte zu integrieren. Seitdem haben wir erhebliche Fortschritte bei der Verbesserung unserer Sicherheitslage gemacht und ein sichereres Ökosystem für unsere Kund(inn)en geschaffen, um sichere Software schneller zu entwickeln.
Die Sicherheitsziele erreichen
Schauen wir uns die Erweiterungen und Verbesserungen an, die wir vorgenommen haben, um die Sicherheit über den gesamten Entwicklungslebenszyklus hinweg weiter zu verbessern.
Multi-Faktor-Authentifizierung (MFA)
Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens nachweisbare Maßnahmen zur messbaren Erhöhung der Nutzung von Multi-Faktor-Authentifizierung in den Produkten des Herstellers demonstrieren.
GitLab bietet derzeit mehrere MFA-Optionen für Nutzer(innen), um ihre Konten zu sichern. Wir bieten auch SSO-Funktionalität an, damit GitLab.com-, Self-Managed- und GitLab Dedicated-Kund(inn)en ihre Authentifizierungsprozesse und internen MFA-Anforderungen optimieren können.
Um die Widerstandsfähigkeit der Plattform weiter zu verbessern und eine sicherere Grundlage für unsere Kund(inn)en zu schaffen, führt GitLab eine schrittweise MFA-by-Default-Einführung durch.
In den kommenden Monaten werden wir Änderungen implementieren, die alle Kund(inn)en verpflichten, MFA für ihre Konten zu aktivieren.
Für Kund(inn)en, die bereits MFA aktiviert haben oder sich über die Single-Sign-On-Methode (SSO) ihrer Organisation bei GitLab authentifizieren, sind keine Änderungen erforderlich. Kund(inn)en, die noch keine MFA aktiviert haben und sich nicht über die SSO-Methode ihrer Organisation bei GitLab authentifizieren, müssen MFA aktivieren und sich für eine oder mehrere der verfügbaren MFA-Methoden registrieren.
Die MFA-Einführung erfolgt in Phasen, um eine reibungslose und konsistente Annahme bei allen Kund(inn)en zu gewährleisten. Weitere Details zu GitLabs MFA-by-Default-Einführung werden in naher Zukunft geteilt.
Standardpasswörter
Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens messbaren Fortschritt bei der Reduzierung von Standardpasswörtern in den Produkten des Herstellers demonstrieren.
Um die Verwendung von Standardpasswörtern zu reduzieren, nutzt GitLab zufällig generierte Root-Passwörter für seine verschiedenen Installationsmethoden. GitLabs Installationsanweisungen für mehrere Methoden enthalten auch Anleitungen, wie das zufällig generierte Root-Passwort für jede Installation geändert werden kann.
Bei einigen Installationsmethoden, wie der Installation von GitLab in einem Docker-Container, wird die Passwortdatei mit dem initialen Root-Passwort beim ersten Container-Neustart nach 24 Stunden gelöscht, um die GitLab-Instanz weiter zu härten.
Reduzierung ganzer Klassen von Schwachstellen
Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Maßnahmen demonstrieren, die eine signifikante messbare Reduzierung der Verbreitung einer oder mehrerer Schwachstellenklassen in den Produkten des Herstellers ermöglichen.
GitLab hat Richtlinien für sicheres Programmieren auf seiner Dokumentationsseite veröffentlicht, die Beschreibungen und Richtlinien zur Behebung von Sicherheitsschwachstellen enthalten, die häufig in der GitLab-Codebasis identifiziert werden.
Die Richtlinien sind „darauf ausgelegt, Entwickler(inne)n zu helfen, potenzielle Sicherheitsschwachstellen frühzeitig zu identifizieren, mit dem Ziel, die Anzahl der im Laufe der Zeit veröffentlichten Schwachstellen zu reduzieren."
GitLab verbessert kontinuierlich seine SAST-Regelabdeckung, um umfassendere Sicherheitsschwachstellen für sich selbst und seine Kund(inn)en zu adressieren.
Sicherheitspatches
Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Maßnahmen demonstrieren, um die Installation von Sicherheitspatches durch Kund(inn)en messbar zu erhöhen.
GitLab übernimmt alle Updates im Zusammenhang mit seinen GitLab.com- und GitLab Dedicated-Serviceangeboten. Zusätzlich veröffentlicht GitLab eine Wartungsrichtlinie, die den Ansatz für die Veröffentlichung von Updates, Rückportierungen, Upgrade-Empfehlungen und unterstützende Dokumentation usw. darlegt.
Die GitLab-Dokumentation bietet umfassende Anleitungen zum Upgrade von Self-Managed-Instanzen basierend auf ihrem Bereitstellungsmodell. Dies umfasst Omnibus-, Helm-Chart-, Docker- und selbstkompilierte GitLab-Installationen.
GitLab bietet auch einen detaillierten Upgrade-Plan, um ordnungsgemäße Tests und Fehlerbehebung sowie bei Bedarf Rollback-Pläne zu gewährleisten.
Je nach Versions-Upgrade werden spezifische Änderungen (Beispiel für GitLab 17) für jede Version hervorgehoben, um einen reibungslosen Upgrade-Prozess zu gewährleisten und die Nichtverfügbarkeit von Diensten zu begrenzen.
Richtlinie zur Offenlegung von Schwachstellen
Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens eine Richtlinie zur Offenlegung von Schwachstellen (VDP) veröffentlichen.
GitLab unterhält ein starkes Bug-Bounty-Programm über HackerOne, eine security.txt-Datei, die GitLabs bevorzugte und zusätzliche Offenlegungsprozesse hervorhebt, sowie Release-Posts, die Sicherheitsfixes hervorheben.
Kund(inn)en und die Öffentlichkeit können sich anmelden, um GitLabs Release-Posts direkt in ihrem E-Mail-Posteingang zu erhalten.
Common Vulnerability Enumerations
Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens Transparenz in der Schwachstellenberichterstattung demonstrieren
GitLab fügt das Common Weakness Enumeration (CWE)-Feld in alle Common Vulnerability Enumeration (CVE)-Datensätze ein, die es veröffentlicht. Im vergangenen Jahr hat GitLab iterativ auch das Common Platform Enumeration (CPE)-Feld in CVE-Datensätzen aufgenommen.
Das GitLab CVE-Zuweisungsprojekt speichert eine Kopie aller CVE-Identifikatoren, die von GitLab in seiner Rolle als CVE Numbering Authority zugewiesen und veröffentlicht wurden.
Schau dir GitLabs CVE-Einreichungsvorlage an.
Beweise für Eindringlinge
Ziel: Innerhalb eines Jahres nach Unterzeichnung des Versprechens eine messbare Erhöhung der Fähigkeit von Kund(inn)en demonstrieren, Beweise für Cybersicherheitseindringlinge zu sammeln, die die Produkte des Herstellers betreffen.
GitLab hat einen Leitfaden zur Vorfallreaktion veröffentlicht, um Kund(inn)en bei der Reaktion auf Vorfälle mit GitLab-Instanzen zu helfen. Zusätzlich hat GitLab Open-Source-Versionen seiner GUARD Detection-as-Code- und TLDR-Bedrohungserkennungs-Frameworks veröffentlicht. Die Repositories für diese Open-Source-Frameworks finden sich im GitLab Open Source Security Center.
In ähnlicher Weise fügt GitLab Funktionalität zu seinem GitLab.com-Serviceangebot hinzu, um kompromittierte Passwörter zu erkennen für alle Anmeldungen, die GitLabs native Benutzername- und Passwort-Authentifizierungsmethode verwenden.
Was kommt als Nächstes
Die Mission der GitLab Security Division ist es, allen zu ermöglichen, auf einer sicheren, geschützten und vertrauenswürdigen DevSecOps-Plattform zu innovieren und erfolgreich zu sein.
GitLabs Sicherheitsverbesserungen im vergangenen Jahr haben es uns ermöglicht, unser Engagement für CISAs Secure by Design Pledge zu demonstrieren, und sie haben unsere Plattform gestärkt und Kund(inn)en eine zuverlässigere und sicherere Grundlage zum Aufbauen gegeben.
Unser Engagement für Iteration bedeutet, dass wir uns bereits auf die nächste Reihe von Innovationen konzentrieren, die uns voranbringen werden.
Um mehr über GitLabs Sicherheitsverbesserungen zu erfahren, setze ein Lesezeichen für unsere Sicherheitsseite im GitLab Blog.