In den vorherigen neun Sessions haben Patrick Steger und ich eine GitHub DevSecOps-Pipeline gebaut mit Build, SCA, License Compliance, SAST, Container Scanning, Secret Detection und DAST. Alles nützlich — aber nur dann, wenn sie tatsächlich läuft, bevor Code in main landet, und nur dann, wenn der Merge blockiert wird, sobald etwas Ernstes auftaucht. In Teil 10 verdrahten wir dieses Gate mit Pull Requests und Branch Protection Rules.
Nachdem wir die GitLab DevSecOps Serie abgeschlossen haben, hat Patrick den Job gewechselt — und sein neues Team arbeitet mit GitHub. Das Problem ist dasselbe: keine Security-Checks während der Entwicklung. Die Plattform ist eine andere. In Teil 1 unserer GitHub DevSecOps Serie zeigen wir, was GitHub ist, welches CI/CD-Vokabular man teilen muss, bevor irgendein Pipeline-Gespräch funktioniert, und wie die DevSecOps-Pipeline aussieht, die wir in den nächsten Sessions aufbauen werden.
In den vorherigen neun Sessions haben Patrick Steger und ich eine GitLab DevSecOps-Pipeline gebaut, die SAST, Secret Detection, Software Composition Analysis, Container Scanning und DAST ausführt. Nützlich — aber nur dann, wenn sie Probleme tatsächlich findet, bevor der Code im Default-Branch landet. In Teil 10 schliessen wir diesen Loop: Wir hängen die Pipeline an Merge Requests, sodass jede Änderung gescannt wird, die Deltas gegen den Default-Branch sichtbar sind, und Freigaben erforderlich werden, wenn neue High- oder Critical-Vulnerabilities auftauchen.
Alles, was wir bisher in der GitLab DevSecOps Pipeline gemacht haben, war statisch — Analyse von Source Code, Dependencies, Containern und Konfiguration. In Teil 8 überschreiten Patrick Steger und ich die Linie zu Continuous Delivery und ergänzen Dynamic Application Security Testing. DAST heisst: Wir deployen die Anwendung, starten sie und greifen sie von aussen mit einem automatisierten Penetration-Testing-Tool an. GitLab liefert das Feature out of the box mit OWASP ZAP.
Wir haben SAST, Secret Detection und Software Composition Analysis bereits in die GitLab-Pipeline integriert. Diese Checks decken Quellcode und Dependencies ab — aber das Artefakt, das wir tatsächlich ausliefern, ist ein Container-Image. Betriebssystem-Pakete, das Base-Image und alles, was im Lauf des Builds hineinkopiert wird, können eigene Schwachstellen mitbringen. In Teil 6 unserer Serie ergänzen Patrick Steger und ich die Pipeline um Container Scanning, bauen ein Docker-Image aus dem zuvor kompilierten Jar und schicken es durch Trivy und Grype.
Du lieferst eine Java-Anwendung aus, die von Spring Boot abhängt, das wiederum von dutzenden weiteren Bibliotheken abhängt — jede mit ihrer eigenen Lizenz. Und die meisten Teams können dir nicht sagen, welche Lizenzen das eigentlich sind. In Teil 4 unserer GitLab DevSecOps Serie ergänzen Patrick Steger und ich die Pipeline um License Compliance, sodass diese Frage bei jedem Commit automatisch beantwortet wird. Die gute Nachricht: Mit GitLab Ultimate ist das eine Template-Zeile.
Warum wird Security immer noch am Ende des Entwicklungsprozesses angeflanscht — und wie können wir sie nach vorn verschieben, ohne die Teams auszubremsen? In Teil 1 unserer GitLab DevSecOps Serie legen Patrick Steger und ich die Grundlage: Was GitLab ist, was Shift Left wirklich bedeutet und welche CI/CD-Konzepte man verstanden haben muss, bevor man eine DevSecOps-Pipeline bauen kann, die in der Praxis funktioniert.
