GitLab Ultimate vs. GitHub Security: Der vollständige Vergleich und Migrationsleitfaden 2025

GitLab ist die umfassendste KI-gestützte DevSecOps-Plattform. Unternehmen können mit dieser Plattform für den gesamten Lebenszyklus der Softwareentwicklung (SDLC) sicherere Software schneller bereitstellen. GitHub bietet eine Advanced Security-Erweiterung, die zusätzliche Sicherheitsfunktionen in GitHub ermöglicht. Es fehlen jedoch die Tiefe und Breite der Sicherheitsfunktionen, die GitLab nativ bereitstellt. Unternehmen, die auf GitLab Ultimate migrieren möchten, um ihre Sicherheit in allen Bereichen des SDLC zu verbessern, können diesen Leitfaden verwenden, um die beiden Angebote zu vergleichen. Er kann auch als Tutorial für den Wechsel zur GitLab-Plattform genutzt werden. Hinweis: Dieser Artikel wurde zuletzt im Juni 2025 aktualisiert, um die neuesten Änderungen in GitHubs Produktstrategie zu berücksichtigen. In diesem Artikel findest du folgende Kapitel: – Ein Vergleich zwischen GitLab Ultimate und GitHub Advanced Security – So migrierst du ein GitHub-Repository zu GitLab – So migrierst du Feature für Feature von GitHub Advanced Security zu GitLab Ultimate – Eine Einführung in die zusätzlichen Sicherheitsfunktionen von GitLab Ultimate

Ein Vergleich zwischen GitLab Ultimate und GitHub Advanced Security

GitLab Ultimate ist die höchste Abonnementstufe von GitLab für Unternehmen, die sichere Software schneller bereitstellen möchten. GitHub Advanced Security ist eine Erweiterung für GitHub Enterprise und ermöglicht zusätzliche Sicherheitsfunktionen. ### Ähnlichkeiten zwischen GitLab Ultimate und GitHub Advanced Security GitLab Ultimate und GitHub Advanced Security bieten: – Statische Anwendungssicherheitstests (SAST), Geheimnis- und Abhängigkeitssuche – kontextbezogene Intelligenz von Sicherheitslücken und Lösungsberatung – eine Liste von Abhängigkeiten oder Software-Stückliste (SBOM) – Sicherheitsmetriken und -einblicke

Unterschiede zwischen GitLab Ultimate und GitHub Advanced Security

Während sich GitHubs Sicherheitstools verbessert haben (mit Push Protection, die 2024 Millionen von Secrets blockiert hat), bietet GitLab Ultimate weiterhin eine tiefere DevSecOps-Integration mit Funktionen, die in GitHubs eigenständigen Produkten nicht verfügbar sind:

• Compliance-Frameworks und Audit-Management
• Sicherheits-Dashboard über gesamte Gruppen/Organisationen
• Native DAST und API-Fuzzing
• Integrierter Workflow für Schwachstellenmanagement
• Benutzerdefinierte Sicherheitsrichtlinien mit granularen Kontrollen Diese integrierten Funktionen bedeuten, dass Teams weniger Zeit mit dem Wechsel zwischen Tools verbringen und mehr Zeit für die Sicherung ihrer Anwendungen haben. GitLab Ultimate bietet auch zusätzliche Sicherheits- und Konformitätsfunktionen, Portfolio- und Wertschöpfungskettenmanagement, Unterstützung bei Live-Upgrades und mehr. Weitere Informationen zu diesen zusätzlichen Funktionen findest du in der GitLab Ultimate-Dokumentation.RetryClaude can make mistakes. Please double-check responses.

Wichtige Änderungen bei GitHub Advanced Security (2025)

Seit April 2025 hat GitHub Advanced Security in zwei separate Produkte aufgeteilt: Secret Protection (19$/Monat pro aktivem Committer) und Code Security (30$/Monat pro aktivem Committer). Obwohl dieser modulare Ansatz kosteneffektiv erscheinen mag, benötigen Organisationen in der Regel beide Produkte für umfassende Sicherheitsabdeckung, was zu 49$/Monat pro aktivem Committer führt - wodurch GitLab Ultimates einheitlicher Ansatz für Teams, die vollständige Sicherheitsfunktionen benötigen, potenziell wirtschaftlicher ist. GitHub bietet diese Sicherheitsprodukte nun auch Team-Plan-Kunden ohne Enterprise-Abonnement an. GitLabs integrierte DevSecOps-Plattform bedeutet jedoch, dass Sicherheitsfunktionen vom ersten Tag an nahtlos mit CI/CD, Projektmanagement und anderen Tools zusammenarbeiten - ohne zusätzliche Käufe oder Integrationen. Diese native Integration führt oft zu schnellerer Implementierung und besseren Sicherheitsergebnissen.

So migrierst du ein GitHub-Repository zu GitLab

GitLab bietet einen integrierten Importer, mit dem du deine GitHub-Projekte entweder von GitHub.com oder GitHub Enterprise nach GitLab importieren kannst. Mit dem Importer kannst du nicht nur das GitHub-Repository nach GitLab migrieren, sondern auch verschiedene andere Objekte, einschließlich Tickets, Beteiligte (Mitglieder) und Pull Requests. Eine vollständige Liste der migrierbaren Daten findest du in der Dokumentation zum Import von Daten von GitHub. Die Migration wird wie folgt durchgeführt: 1. Wähle oben in der linken Menüleiste Neu erstellen (+) aus. 2. Wähle im Abschnitt In GitLab Neues Projekt/Repositoryaus. 3. Wähle Projekt importieren aus. 4. Wähle die Schaltfläche GitHub aus. – Wenn du GitLab Self-Managed verwendest, musst du den GitHub-Importer aktivieren. – Beachte, dass andere Importer auf dieselbe Weise initiiert werden können. 5. Jetzt kannst du einen der folgenden Schritte ausführen: – Autorisiere dich mit GitHub Oauth, indem du Mit GitHub autorisieren auswählst. – Verwende einen persönlichen GitHub-Zugriffstoken: – Gehe zu https://github.com/settings/tokens/new. – Gib im Feld Hinweis eine Token-Beschreibung ein. – Wähle den Repo-Geltungsbereich aus. – Um Beteiligte zu importieren, wähle optional den Geltungsbereich read:org aus. – Wähle die Schaltfläche Token generieren aus. – Füge auf der GitLab-Importseite im Feld „Persönlicher Zugriffstoken“ den persönlichen GitHub-Zugriffstoken ein. 5. Wähle die Schaltfläche Authentifizieren aus. 6. Wähle die Elemente aus, die du migrieren möchtest. 7. Wähle die Projekte aus, die du migrieren möchtest, und wohin du sie migrieren möchtest. 8. Wähle die Schaltfläche Importieren aus. Dein importiertes Projekt sollte sich nun in deinem Arbeitsbereich befinden. Weitere Informationen über die Migration von GitHub zu GitLab findest du in diesem Video:

variables: SEARCH_MAX_DEPTH: 10

semgrep-sast: variables: SAST_ANALYZER_IMAGE_TAG: "3.7"

gosec-sast: before_script: - | cat < ~/.netrc machine gitlab.com login $CI_DEPLOY_USER password $CI_DEPLOY_PASSWORD EOF

      **Hinweis:** Die verfügbaren SAST-Jobs findest du in der [Vorlage ‚SAST.gitlab-ci.yml‘](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml). Konfigurationen findest du in der [Dokumentation für verfügbare SAST CI/CD Variablen](https://docs.gitlab.com/ee/user/application_security/sast/#available-cicd-variables).
#### Anpassen von SAST-Regelsätzen
Für jeden SAST-Analysator verarbeitet GitLab den Code und verwendet dann Regeln, um mögliche Schwachstellen im Quellcode zu finden. Diese Regeln bestimmen, welche Arten von Schwachstellen der Scanner meldet.
– Für Semgrep-basierte SAST-Scanner erstellt, pflegt und unterstützt GitLab die verwendeten Regeln. Es kombiniert die Open-Source-Engine Semgrep, von GitLab verwaltete Erkennungsregeln und die proprietäre Technologie von GitLab für das Verfolgen von Sicherheitslücken und die Erkennung von falschen positiven Ergebnissen.
– Für andere SAST-Analysatoren werden die Regeln in den Upstream-Projekten für jeden Scanner definiert.
Du kannst das Verhalten der SAST-Scanner anpassen, indem du eine Regelsatz-Konfigurationsdatei im gescannten Repository definierst:
– Vordefinierte Regeln deaktivieren (für alle Analysatoren verfügbar)
– Vordefinierte Regeln überschreiben (für alle Analysatoren verfügbar)
– Vordefinierte Regeln ersetzen, indem du eine benutzerdefinierte Konfiguration mithilfe von Passthroughs synthetisierst
Weitere Informationen und Beispiele zum Konfigurieren von SAST-Regeln findest du in den [SAST-Regeln](https://docs.gitlab.com/ee/user/application_security/sast/rules.html) und in der [Dokumentation zum Anpassen von Regelsätzen](https://docs.gitlab.com/ee/user/application_security/sast/customize_rulesets.html).
### Geheimnissuche
Das GitHub-Feature Geheimnissuche findet, blockiert und widerruft durchgesickerte Geheimnisse. Das Gleiche kannst du in GitLab erreichen, indem du die Funktion [Erkennung von Geheimnissen](https://docs.gitlab.com/ee/user/application_security/secret_detection/) aktivierst.
Um die Erkennung von Geheimnissen in GitLab zu aktivieren, kannst du einfach die folgende Vorlage zu deiner ‚.gitlab-ci.yml‘ hinzufügen:
```yaml
include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

    

Sobald die Vorlage hinzugefügt wurde, scannt der Geheimnisscanner jedes Mal, wenn neuer Code eingecheckt wird (oder eine Pipeline ausgeführt wird), den Quellcode auf bekannte Geheimnisse. Je nach Situation scannt die Erkennung von Geheimnissen für Pipelines verschiedene Aspekte deines Codes. Für alle Methoden außer dem „Standard-Branch“ scannt die Erkennung von Geheimnissen für Pipelines Commits, nicht den Arbeitsbaum. Weitere Informationen zur Geheimnissuche findest du in der Dokumentation zur Erkennung von Geheimnissen. Wenn du einen Merge Request erstellst, scannt die Funktion Erkennung von Geheimnissen jeden Commit, der im Quellbranch vorgenommen wurde. Genau wie in SAST liefert jede erkannte Sicherheitslücke die folgenden Informationen (z. B. Standort) und Bezeichner, um den Behebungsprozess zu unterstützen: Ähnlich wie bei SAST kannst du Maßnahmen gegen diese Sicherheitslücken direkt aus der Merge Request heraus ergreifen, einschließlich des Ignorierens von Sicherheitslücken und des Erstellens von Tickets.

Anpassen von Jobs der Erkennung von Geheimnissen

Mit GitLab kannst du eine Jobdefinition der Erkennung von Geheimnissen überschreiben, sodass du Eigenschaften wie Variablen, Abhängigkeiten oder Regeln ändern kannst. Dazu musst du einen Job mit demselben Namen erstellen, wie der Job zur Erkennung von Geheimnissen, den du überschreiben willst. Platziere dann diesen neuen Job nach dem Einfügen der Vorlage und gib alle zusätzlichen Schlüssel darunter an. Ein Beispiel ist die folgende Konfiguration: – überschreibt die Phase, auf der der Job zur Erkennung von Geheimnissen ausgeführt wird, zu ‚security‘ – ermöglicht Verlaufsscans – ändert die Analysatorversion für Geheimnisse auf 4.5

      include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

secret_detection:
  stage: security
  variables:
    SECRET_DETECTION_HISTORIC_SCAN: "true"
    SECRETS_ANALYZER_VERSION: "4.5"

    

Hinweis: Die verfügbaren Jobs zur Erkennung von Geheimnissen findest du in der Vorlage SAST.gitlab-ci.yml. Verfügbare Konfigurationen findest du in der Dokumentation zu verfügbaren CI/CD-Variablen der Erkennung von Geheimnissen.

Anpassen von Regeln für die Erkennung von Geheimnissen

Mit dem Analysator für die Erkennung von Geheimnissen kannst du anzupassen, welche Geheimnisse in der GitLab-UI gemeldet werden. Die folgenden Anpassungsoptionen können einzeln oder in Kombination verwendet werden: – vordefinierte Regeln deaktivieren – vordefinierte Regeln überschreiben – eine benutzerdefinierte Konfiguration synthetisieren – eine Remote-Konfigurationsdatei spezifizieren Wenn du zum Beispiel die Datei ‚.gitlab/secret-detection-ruleset.toml‘ im Stammverzeichnis deines Projekts erstellst, wird das Standard-GitLeaks-Paket erweitert, sodass Testtoken von der Erkennung ausgeschlossen werden:

      ### extended-gitleaks-config.toml
title = "extension of gitlab's default gitleaks config"

[extend]
### Extends default packaged path
path = "/gitleaks.toml"

[allowlist]
  description = "allow list of test tokens to ignore in detection"
  regexTarget = "match"
  regexes = [
    '''glpat-1234567890abcdefghij''',
  ]

    

Weitere Informationen zum Überschreiben der vordefinierten Analysatorregeln findest du in der Dokumentation zur Erkennung von Geheimnissen.

Automatische Reaktion auf durchgesickerte Geheimnisse

Die Funktion zur Erkennung von Geheimnissen von GitLab reagiert automatisch, wenn sie bestimmte Arten von durchgesickerten Geheimnissen findet. Automatische Antworten können: – das Geheimnis automatisch widerrufen – den Partner, der das Geheimnis ausgestellt hat, benachrichtigen; der Partner kann dann das Geheimnis widerrufen, seine(n) Eigentümer(in) benachrichtigen oder sich auf andere Weise vor Missbrauch schützen GitLab kann Partner auch benachrichtigen, wenn von ihnen ausgestellte Anmeldeinformationen in öffentlichen Repositorys auf GitLab.com durchgesickert sind. Wenn du ein Cloud- oder SaaS-Produkt betreibst und diese Benachrichtigungen erhalten möchtest, kannst du eine Partner-API implementieren, die von der GitLab Token Revocation API aufgerufen wird. Weitere Informationen findest du in der Dokumentation zu automatischen Antworten für durchgesickerte Geheimnisse.

Sicherheit der Lieferkette

Mit GitHub kannst du Software-Lieferketten mit automatisierten Sicherheits- und Versionsaktualisierungen und SBOMs mit einem Klick sichern, verwalten und Berichte darüber erstellen. GitLab kann deine Sicherheitsbedürfnisse in der Lieferkette mithilfe der Funktionen der Abhängigkeitssuche und der Liste der Abhängigkeiten (SBOM) erfüllen. Um das Scannen von Abhängigkeiten in GitLab zu aktivieren, kannst du einfach die folgende Vorlage zu deiner ‚.gitlab-ci.yml‘ hinzufügen:

      include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

    

Sobald die Vorlage hinzugefügt wurde erkennt die Abhängigkeitssuche jedes Mal, wenn neuer Code eingecheckt wird, automatisch die Paketmanager, die in deinem Projekt verwendet werden. Sie scannt dann die verwendeten Abhängigkeiten auf bekannte Schwachstellen. Die Ergebnisse der Abhängigkeitssuche zwischen dem Feature-Branch und dem Zielbranch werden im Merge-Request-Widget angezeigt. Das Merge-Request-Widget zeigt die Ergebnisse der Abhängigkeitssuche, die durch die Änderungen im Merge Request eingeführt wurden, und schlägt Lösungen vor. Innerhalb eines Merge Request werden für jede Sicherheitslücke relevante Informationen angezeigt, die bei der Behebung hilfreich sind, wie Bezeichner, Beweise und Lösungen: Ähnlich wie bei SAST und der Erkennung von Geheimnissen kannst du Maßnahmen gegen diese Sicherheitslücken direkt aus dem Merge Request heraus ergreifen. Dazu gehören das Ignorieren von Sicherheitslücken und das Erstellen von Tickets.

Konfigurieren der Abhängigkeitssuche

Um eine Jobdefinition zu überschreiben (z. B. um Eigenschaften wie Variablen oder Abhängigkeiten zu ändern), erstellst du einen neuen Job mit dem gleichen Namen wie den, den du überschreiben willst. Platziere dann diesen neuen Job nach dem Einfügen der Vorlage und gib alle zusätzlichen Schlüssel darunter an. Ein Beispiel ist der folgende Code: – deaktiviert die automatische Behebung anfälliger Abhängigkeiten – erfordert einen Build-Job, der vor der Abhängigkeitssuche abgeschlossen werden muss

      include:
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

gemnasium-dependency_scanning:
  variables:
    DS_REMEDIATE: "false"
  dependencies: ["build"]

    

Weitere Informationen zur Konfiguration der Abhängigkeitssuche findest du in der Dokumentation zum Anpassen des Verhaltens des Analysators.

Das Generieren eines SBOM

GitLab bietet eine Liste der Abhängigkeiten (Dependency List, SBOM), mit der du die Abhängigkeiten deines Projekts oder deiner Gruppe sowie wichtige Details zu diesen Abhängigkeiten, einschließlich ihrer bekannten Sicherheitslücken, überprüfen kannst. Diese Liste ist eine Ansammlung von Abhängigkeiten in deinem Projekt, einschließlich bestehender und neuer Resultate. Die Liste der Abhängigkeiten wird generiert, nachdem die Abhängigkeitssuche erfolgreich auf dem Standard-Branch ausgeführt wurde. So greifst du auf die Liste der Abhängigkeiten zu: 1. Wähle in der linken Seitenleiste Suchen oder aufrufen aus und suche nach deinem Projekt. 2. Wähle Sicher > Liste der Abhängigkeiten aus. Hier findest du die folgenden Informationen zu deinen Abhängigkeiten: