von Romano Roth und Patrick Steger
Diese Videoserie zeigt Ihnen, wie Sie eine enterprise-taugliche DevSecOps-Pipeline mit GitLab und GitHub aufbauen, und vergleicht die beiden Plattformen miteinander.
Einführung#
GitLab
GitHub
| Thema | GitLab | GitHub |
|---|---|---|
| Security Tools | Bietet Integrationspunkte zur Einbindung von Security Tools. Stellt von GitLab gewartete Integrationen für die von GitLab empfohlenen Standard-Security-Tools bereit. | Bietet Integrationspunkte zur Einbindung von Security Tools. Es gibt keine von GitHub empfohlenen oder gewarteten Standard-Security-Tools. Es gibt von der Community bereitgestellte Tools für Open Source und kommerzielle Lösungen. |
Erstellen eines einfachen Projekts#
GitLab
GitHub
| Aspekt | GitLab | GitHub |
|---|---|---|
| Repository erstellen | Kann ein neues leeres Repository erstellen. Bietet die Möglichkeit, mit einer von GitLab bereitgestellten Standard-Projekt-/Repo-Struktur zu starten (z. B. C#, SpringBoot, PHP usw.). Diese sind leicht auffindbar. | Kann ein neues leeres Repository erstellen. Kann ein neues Repository basierend auf einem Template-Projekt erstellen. Template-Projekte sind schwer zu finden, wenn keine in Ihrer Organisation vorhanden sind. |
| Import | Kann aus anderen Repositories wie jedem Git-Repository (URL), GitHub, Jira, Bitbucket usw. importieren. | Kann aus bestehenden Repositories importieren. Auch aus GitLab. Funktioniert allerdings nicht bei Verwendung von Social-Login. |
| Pipeline-Definition | .gitlab-ci.yml ist der Einstiegspunkt, der die gesamte Pipeline definiert. Option, weitere Dateien einzubinden (deren Inhalt wird zur Laufzeit automatisch eingebunden). | Pipelines werden Workflows genannt. Wir können für jeden Workflow eine eigene Datei haben. Innerhalb der Workflow-Datei definieren wir, was den Workflow/die Pipeline auslöst. Es ist möglich, aus einer Workflow-Datei “Sub-Workflows” aufzurufen. |
| Pipeline-Struktur | Die Pipeline ist in Stages und Jobs unterteilt, wobei Stages nacheinander ausgeführt werden und alle Jobs einer Stage parallel laufen (Abhängigkeiten können konfiguriert werden). Das ist ein sehr eleganter Ansatz, kann aber bei komplexen Pipelines schwer verständlich werden. | Pipelines/Workflows sind im UI sauber getrennt und erleichtern das Auffinden des richtigen Workflows/der richtigen Pipeline. Workflows nutzen Actions, um Jobs/Steps zu implementieren. Solche Actions sind über einen Marketplace verfügbar und nicht immer leicht zu finden. |
| Einfacher Einstieg | Sehr einfach, eine erste einfache Pipeline zu erstellen, da GitLab Defaults für fast alles bereitstellt, was zum Start benötigt wird. | Recht komplex, die erste einfache Pipeline zum Laufen zu bringen, da GitHub nicht viel automatisch bereitstellt. |
| Pipeline Runs | Pipeline-Läufe finden Sie im Menü CI/CD -> Pipelines. | Pipeline-/Workflow-Läufe sind im UI im Tab “Actions” sauber pro Workflow aufgelistet. |
| Artefakte | Artefakte können einfach deklariert werden und stehen dann in der Pipeline-Ergebnisansicht zum Download bereit. Dies wird von GitLab bereitgestellt und ist gut dokumentiert. Standard-Artefakte wie Test-Ergebnisse können mit Standard-GitLab-Funktionalität im GitLab-UI sichtbar gemacht werden. | Artefakte werden über eine Action verfügbar gemacht (z. B. mit der upload-artifact Action aus dem Marketplace). Standard-Artefakte wie Test-Ergebnisse erfordern weitere Actions aus dem Marketplace. Die UI-Qualität variiert. |
| Mehrere Pipelines | Verschiedene Pipelines müssen mit Regeln konfiguriert werden (z. B. basierend darauf, auf welchen Branch committet wurde). Dies kann bei komplexen Szenarien kompliziert werden. | Verschiedene Pipelines werden einfach in zusätzlichen Workflow-Dateien konfiguriert. Dies wird mit der Zeit natürlich und unterstützt komplexe Szenarien. |
| Visualisierung | Schöne grafische Ansicht zur Visualisierung von Stages und Jobs sowie deren Abhängigkeiten (jedoch nicht der Bedingungen). | Schöne grafische Ansicht zur Visualisierung des Workflow-/Pipeline-Laufs für ausgeführte Runs. |
Software Composition Analysis (SCA)#
GitLab
GitHub
| Aspekt | GitLab | GitHub |
|---|---|---|
| Standard-Tool | Von GitLab bereitgestellter Open-Source-Scanner verfügbar, dokumentiert und leicht auffindbar. Einfach ein von GitLab bereitgestelltes Template hinzufügen. | Kein von GitHub bereitgestelltes Standard-Tool. Eines im Marketplace finden. Wir wählten CRDA von RedHat basierend auf Snyk (was sich als nicht enterprise-tauglich erwies). |
| Tool-Qualität | Das Standard-Tool hat eine angemessene Qualität und Findings und ist enterprise-tauglich. | Marketplace-Tools (Actions) werden von Drittanbietern bereitgestellt. Seien Sie sich des Risikos bewusst und überlegen Sie, welchen Anbietern Sie vertrauen. |
| Integration | Findings sind gut im GitLab-UI integriert (Pipeline-Ansicht, Security & Compliance -> Vulnerability Report). Vulnerabilities sind auch als Download (json) verfügbar. | GitHub verfügt über eine integrierte Funktionalität namens Dependabot, die in den Einstellungen aktiviert werden kann und regelmässige, geplante Scans von unverändertem Code ermöglicht. |
| Format | GitLab verwendet ein GitLab-spezifisches Format zur Integration von Vulnerabilities im GitLab-UI. | Das GitHub-Format zur Anzeige von Vulnerabilities basiert auf Standards. Dies erweist sich als besser für individuelle Integrationen. |
| Geplante Scans | Keine eingebauten geplanten Re-Scans, können aber explizit definiert werden. | Dependabot kann auf neue Findings hinweisen und Pull Requests für bekannte Fixes anbieten. Wird aber nicht beim Commit ausgeführt und kann Merges nicht blockieren. |
| Besonderheit | Vergleichsweise einfacher Editor für Dateien im Projekt. | Vollständig integrierte Entwicklungsumgebung (ähnlich wie Visual Studio Code). Dies hat sich als sehr leistungsstark erwiesen. |
License Compliance#
GitLab
GitHub
| Aspekt | GitLab | GitHub |
|---|---|---|
| Tool | License Compliance wird als verwaltetes GitLab-Tool bereitgestellt (basierend auf dem Open-Source-Projekt License-Finder), das einfach und unkompliziert hinzugefügt werden kann. | Erfordert eine Community-bereitgestellte (Marketplace) oder eine eigene Action zur Implementierung. Es ist sinnvoll, dafür einen eigenen Sub-Workflow zu definieren. |
| Konfiguration | Alle verwendeten Lizenzen des Projekts sind in einem Standard-GitLab-UI sichtbar. Akzeptable Lizenzen können als Teil der Plattform (Projekteinstellungen) konfiguriert werden. | Es kann definiert werden, welche Lizenzen konfigurierbar sind, und eine fehlerhafte/fehlgeschlagene Pipeline wird ausgelöst, wenn andere Lizenzen gefunden werden. |
| Workflow | Unterstützung grundlegender Workflows zur Verifizierung und Akzeptanz neuer Lizenzen (z. B. Einbindung eines Security-Team-Mitglieds als Akzeptierender/Reviewer). | Fehlgeschlagene Lizenzen werden als “angepasste Test-Ergebnisse” gemeldet. Ergebnisse sind nur im Pipeline-Lauf sichtbar. |
| Sichtbarkeit | Fehlgeschlagene (nicht als akzeptabel markierte) Lizenzen werden gemeldet. | Es gibt keinen einfachen Weg, “alle vom Projekt verwendeten Lizenzen” zu sehen (dies ist nur in der Log-Ausgabe des Pipeline-Laufs verfügbar). |
Static Application Security Testing (SAST)#
GitLab
GitHub
| Aspekt | GitLab | GitHub |
|---|---|---|
| Standard-Tool | Von GitLab bereitgestelltes Standard-Tool basierend auf semgrep und anderen Open-Source-Tools (z. B. spotbugs) verfügbar. Mit wenigen Konfigurationszeilen einfach zu integrieren. | GitHub stellt ein Standard-Tool für statische Analyse bereit (CodeQL). Wir haben zusätzlich die Open-Source-Tools semgrep und spotbugs hinzugefügt. |
| Qualität | GitLab hat zusätzliche Regeln zu den Open-Source-Tools hinzugefügt, sodass weit mehr Sicherheitsprobleme gefunden werden als beim einfachen Open-Source-semgrep-Tool. Insgesamt sehen die Findings gut genug aus. | Die kombinierten Ergebnisse aller drei Tools übersehen immer noch wichtige Findings. Eigene Arbeit (z. B. Definition eigener Regeln) oder zusätzliche Lizenzen sind erforderlich, um sich zu verbessern. |
| Marketplace | N/A | Das Finden geeigneter SAST-Tools (Actions) im Marketplace ist nicht trivial. Viele Tools erfordern Lizenzen. |
| Integration | Findings der Tools sind im GitLab-Benutzeroberfläche integriert (Vulnerability-Ansicht). | Findings der Tools (sie müssen sarif unterstützen) sind in der GitHub-Benutzeroberfläche integriert (Security-Tab). |
Container Scanning#
GitLab
GitHub
| Aspekt | GitLab | GitHub |
|---|---|---|
| Tool | Standard-Tool von GitLab bereitgestellt (basierend auf Trivy und Grype). Einfach hinzuzufügen. | Kein GitHub-Standard. Wir haben Trivy als Container-Scanner ausgewählt; man muss ihn im Marketplace finden. |
| Integration | Das Ergebnis wird im GitLab-UI an zwei Stellen integriert: im Pipeline-Lauf und im Vulnerability Report. | Ergebnisse werden im GitHub-UI unter Security -> Code Scanning integriert (sofern sie einen sarif-Report bereitstellen). |
| Findings | Findings sind angemessen gut. | Findings sind angemessen gut (mit unserem ausgewählten Tool). Duplikate mit SCA können auftreten. |
| Container Registry | Das Erstellen eines Container-Images und das Bereitstellen in der Standard-Container-Registry erfordert etwas mehr Aufwand, ist aber dokumentiert. | Das Erstellen eines Containers und das Bereitstellen in der Container-Registry ist angemessen dokumentiert, aber nicht trivial. |
| Pipeline-Abbruch | Findings brechen die Pipeline nicht ab; sie werden lediglich gemeldet. Wir können GitLab nicht so konfigurieren, dass eine Pipeline beim Auffinden von Vulnerabilities abgebrochen wird. | Findings brechen die Pipeline nicht ab; sie werden lediglich gemeldet. Den Abbruch der Pipeline zu erreichen, erfordert etwas individuellen Aufwand. |
Secret Detection#
GitLab
GitHub
| Aspekt | GitLab | GitHub |
|---|---|---|
| Tool | GitLab stellt ein Standard-Tool basierend auf GitLeaks bereit. Die Integration ist einfach. | GitHub verfügt über eine integrierte Funktionalität für Secrets. Die Integration ist einfach. |
| Fähigkeiten | Gefundene Secrets sind begrenzt; ein gutes SCA-Tool wird als Ergänzung benötigt. Der Fokus von GitLeaks liegt auf Security-Tokens (z. B. AWS Access Tokens), nicht auf regulären Schlüsseln oder Passwörtern. | Findet Secrets im Repository. Gefundene Secrets sind begrenzt. Der Fokus liegt auf Security-Tokens, nicht auf regulären Schlüsseln oder Passwörtern. Sie können eigene Secret-Patterns definieren und testen. |
| Integration | Findings werden im GitLab-UI gemeldet; sowohl in der Pipeline als auch im Vulnerability Report. | Zum Zeitpunkt der Aufnahme des Videos funktionierte der “Push Protection” für Secrets nicht. |
| Secret Storage | GitLab hat keinen integrierten sicheren Weg, Secrets zu speichern. Sie unterstützen HashiCorp Vault, der Vault muss aber anderswo gehostet und von Ihnen verwaltet werden. | GitHub hat einen gut geschützten Secrets-Bereich, in dem Secrets sicher gespeichert werden können. UND sie unterstützen ausserdem Azure KeyVault out-of-the-box. Ein riesiger Pluspunkt. |
Dynamic Application Security Testing (DAST)#
GitLab
GitHub
| Aspekt | GitLab | GitHub |
|---|---|---|
| Tool | Bietet Standard-Tooling basierend auf OWASP ZAP. | Keine Out-of-the-Box-Lösung. Wir wählten OWASP ZAP basierend auf der Action zaproxy/action-full-scan. |
| Fähigkeiten | Scan-Fähigkeiten sind out-of-the-box sehr begrenzt, erfordern erhebliche Konfiguration. Out-of-the-Box-Findings sind meist irrelevant. | Scan-Fähigkeiten sind out-of-the-box begrenzt, aber Ergebnisse besser als in GitLab. |
| Container | Es muss zuerst ein Container erstellt werden, der gestartet werden kann, um DAST dagegen auszuführen. Der Container kann in der GitLab-internen Laufzeitumgebung gestartet werden. | Es muss zuerst ein Container erstellt werden. Der Container kann in GitHub mit einem Ubuntu-Image gestartet werden, auf dem Docker installiert ist. |
| Integration | Ergebnisse sind schön im Pipeline-Lauf integriert. Ergebnisse sind auch im Vulnerability-Management-Report des GitLab-UI zu finden. | Ergebnisse sind nicht im GitHub-UI integriert. Es wird lediglich ein eigenständiger Report bereitgestellt. Der Grund ist die fehlende sarif-Unterstützung in OWASP ZAP. |
Vulnerability Management#
GitLab
GitHub
| Aspekt | GitLab | GitHub |
|---|---|---|
| Funktionalität | GitLab bietet Funktionalität, um Vulnerabilities im Plattform-UI zu verwalten. Sie können Vulnerabilities manuell hinzufügen. | GitHub bietet begrenzte Funktionalität, um Vulnerabilities im Plattform-UI zu verwalten. Am kritischsten fehlt: die Fähigkeit, eigene Vulnerabilities/Findings hinzuzufügen. |
| Verwerfen | Das Verwerfen eines Findings ist möglich, aber ohne Begründung. Am meisten fehlt uns die Fähigkeit, eine Beschreibung hinzuzufügen, warum wir ein Finding verworfen haben. | Das Verwerfen von Findings als False Positive, “won’t fix” (akzeptiertes Risiko) oder “test code only” ist mit einem Kommentar möglich. |
| Issues | Sie können aus einer Vulnerability ein Issue erstellen -> “Developer Task”. | Sie können aus einer Vulnerability/einem Finding ein Issue erstellen -> “Developer Task”. |
| Auflösen | Sie können Findings manuell als gelöst markieren oder die automatisch erkannte Auflösung akzeptieren. | Auflösen ist nur automatisch möglich. Keine Markierung als “fixed” im Vulnerability Management. |
| Integration | Es ist zwar möglich, Findings zusätzlicher Tools zu integrieren, sie werden jedoch in einem nicht standardisierten Format benötigt, was schwer zu erhalten ist. | Sie können Findings zusätzlicher Tools integrieren, wenn diese den Report im sarif-Format liefern. |
| Einschränkungen | N/A | Sie können nicht für eine begrenzte Zeit verwerfen. Sie können den Schweregrad eines Findings nicht ändern. |
Merge Request / Pull Request#
GitLab
GitHub
| Aspekt | GitLab | GitHub |
|---|---|---|
| Branch Protection | Sie können Branches schützen, sodass Merge Requests verpflichtend sind. | Sie können erzwingen, dass Pull Requests für einen Branch verpflichtend sind. |
| Security Findings | Listet das Delta der Security Findings zwischen dem gemergten und dem Default-Branch auf. Deltas und Findings sind für alle in GitLab integrierten Security Tools verfügbar. | Sie können einige Ergebnisse der Security Tools darstellen; eine erhebliche Anpassung ist erforderlich, um eine akzeptable Qualität zu erreichen. |
| Darstellung | Deltas/Findings werden schön dargestellt und können angesteuert werden. | Neue Findings sind dann in gewissem Umfang für die Security Tools (Checks) verfügbar. Aufgelöste Findings sind nicht sichtbar. Findings werden nicht über Tools hinweg aggregiert. |
| Approvals | Sie können definierte Personen festlegen, die berechtigt sind zu genehmigen, wenn neue Vulnerabilities einer bestimmten Kritikalität gefunden werden. | Sie können definierte Personen festlegen, die berechtigt sind, den Pull Request zu genehmigen, dies basiert jedoch nicht auf neuen Findings/Vulnerabilities. |
| Weitere Infos | Sie sehen auch nicht-sicherheitsbezogene Aspekte wie: Code-Änderungen, Review-Kommentare, Test-Ergebnisse, Pipeline-Läufe. | Sie sehen auch nicht-sicherheitsbezogene Aspekte wie: Code-Änderungen, Review-Kommentare, Test-Ergebnisse. |
Schedule Pipeline#
GitLab
GitHub
| Aspekt | GitLab | GitHub |
|---|---|---|
| Trigger | Wird durch einen dedizierten Scheduler in GitLab ausgelöst. | Wird direkt aus einer Workflow-Definitionsdatei heraus ausgelöst. |
| Branch-Auswahl | Sie können den Branch frei wählen, auf dem er ausgeführt werden soll. | Wird immer nur auf dem Default-Branch ausgeführt, was höchstwahrscheinlich nicht das ist, was Sie brauchen. Es gibt (komplizierte) Workarounds, um die Ausführung auf einem anderen Branch auszulösen. |
| Konfiguration | Sie müssen die Pipeline-Definitionsdatei erweitern, um zu erkennen, wann ein Scheduler den Lauf ausgelöst hat (um nicht benötigte Jobs auszuschliessen, den Pipeline-Lauf anzupassen usw.). | Erstellen Sie eine dedizierte Workflow-Datei dafür. Dieser neue Workflow enthält nur Jobs, die für Security-Checks auf dem Production-Branch/-Code erforderlich sind. |
Unsere Empfehlung#
GitLab
GitHub
| GitLab | GitHub |
|---|---|
| Default-Branch definieren: Dies ist der Branch, der von GitLab verwendet wird, um Security Vulnerabilities im integrierten Vulnerability-Management-Tool anzuzeigen. | Top-Level-Workflows (Pipelines) erstellen, die (einfachere) Workflows zu vollständigen DevSecOps-Pipelines orchestrieren. |
| Eine geplante Pipeline definieren: Damit stellen Sie sicher, dass Sie Ihren Production-Code auf neue Vulnerabilities scannen. | Wiederverwendbare Workflows auf Job-Ebene definieren. |
| Merge Requests verwenden: Um die Auswirkungen von Änderungen auf die Security-Posture zu visualisieren. | Definieren Sie, auf welchen Branches Pipelines ausgeführt werden sollen. |
| Erwägen Sie die Verwendung eines Vault zur Speicherung von Credentials: GitLab hat keine wirkliche Lösung integriert. Sie sollten ein Drittanbieter-Tool in Betracht ziehen. | Eine geplante Pipeline für den aktuellen Production-Release-Branch definieren. |
| Erwägen Sie den Einsatz von Out-of-the-Box-GitLab-Tooling: Dies vereinfacht die Sache erheblich und gibt Ihnen einen Vorsprung beim Einsatz potenziell “gerade-gut-genug”-Tools relativ kostengünstig. | Pull Requests verwenden, um neu eingeführte Sicherheitsprobleme zu finden. Die Summary-Ansicht ist weniger ideal. |
| DAST: Vergessen Sie nicht, die Scanner-Konfiguration anzupassen: Ohne Anpassung sind die Ergebnisse schwach. | Nutzen Sie die Möglichkeit, Branches zu schützen. Mindestens der Release-Branch sollte geschützt werden. |
| (Security-)Reviewen Sie die Tools, die Sie aus dem Marketplace beziehen. | |
| Nutzen Sie die von GitHub bereitgestellten Standard-GitHub-Secrets zur Speicherung von Secrets oder verwenden Sie den professionellen Azure Key Vault. | |
| Evaluieren Sie Security Tools und nutzen Sie ein Set, das für Sie gut genug funktioniert. Leider gibt es kein Out-of-the-Box-Standard-Tooling. | |
| DAST: Vergessen Sie nicht, die Scanner-Konfiguration anzupassen. | |
| Bis GitHub die Möglichkeit bietet, Vulnerabilities manuell hinzuzufügen, müssen Sie möglicherweise ein zusätzliches Tool zur Nachverfolgung von Vulnerabilities verwenden. |
Code#
| GitLab | GitHub |
|---|---|
| https://gitlab.com/romano_roth/gitlabdevsecopspipeline | https://github.com/romanoroth/GitHubDevSecOps |
Zusammenfassung#
Unsere epische Reise geht zu Ende. Im letzten Monat haben wir 24 Videos erstellt, 12 zu GitLab und 12 zu GitHub, in denen wir eine DevSecOps-Pipeline aufgebaut haben. Nun, in diesem 25. Video, vergleichen wir GitLab vs. GitHub.
📌 GitLab liefert schneller Ergebnisse und verfügt über Out-of-the-Box-Tooling für alles, ihm fehlt jedoch ein ordentliches Secret Management.
➡️ GitLab ist unsere Empfehlung, wenn Sie schnell ans Ziel kommen wollen und damit einverstanden sind, sich an die Defaults zu halten.
📌 GitHub bietet mehr Flexibilität, unterstützt grossartiges Secret Management und hat eine lebendige Community, kommt aber mit hohem Supply-Chain-Risiko, hat keine vernünftigen Security-Tool-Defaults und es fehlt ein kritisches Vulnerability-Management-Feature (externe Vulnerability hinzufügen).
➡️ GitHub ist unsere Empfehlung, wenn Sie komplexe Anwendungen/Pipelines haben oder mit einigen externen (Security-)Tools integrieren müssen.
💡 Egal ob Sie Entwickler, Projektmanager oder einfach jemand sind, der sich für Technologie interessiert, unsere Empfehlungen können Ihnen helfen, eine fundierte Entscheidung darüber zu treffen, welche Plattform für Sie am besten geeignet ist.