In diesem Konferenzvortrag bespreche ich eines der grundlegendsten Themen in DevOps: das Denken in Systemen und Wertströmen. Wenn ich mit Unternehmen an ihren DevOps-Transformationen arbeite, sehe ich immer wieder dieselben Muster. Das Business hat tolle Ideen. Diese werden in Word-Dokumente und Jira-Tickets geschrieben. Dann werden sie über die Mauer der Verwirrung zum Entwicklungsteam geworfen. Das Entwicklungsteam baut etwas und wirft es zum Testing. Das Testing vergleicht die Spezifikation mit dem Gebauten (was nie ganz übereinstimmt), testet etwas und wirft es zum Betrieb. Der Betrieb fragt: “Wie sollen wir das betreiben?” Und irgendwie, mit grossem Aufwand, bringen sie es zum Laufen. Dann sieht der Kunde das Ergebnis und sagt: “Was ist das? Das haben wir nicht bestellt.”
Nach acht Sessions, in denen wir Scanner in unsere GitLab-Pipeline eingebaut haben — SAST, Secret Detection, SCA, License Compliance, Container Scanning, DAST — haben wir jetzt ein anderes Problem. Wir haben hunderte von Vulnerability-Findings. In Teil 9 schauen Patrick Steger und ich uns das eingebaute Vulnerability Management von GitLab an: was es liefert, wo es schwächelt und wie man Findings tatsächlich triagiert, ohne den Überblick zu verlieren.
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.
Hardcodierte Passwörter und API-Keys sind nach wie vor einer der häufigsten Wege, auf denen Credentials nach aussen gelangen. Sie werden versehentlich committet, bleiben für immer in der Git-History und tauchen meist erst dann auf, wenn sie schon ausgenutzt werden. In Teil 7 unserer GitLab DevSecOps Serie ergänzen Patrick Steger und ich die bestehende Pipeline um Secret Detection — eine Zeile YAML — und schauen dann ehrlich hin: Was findet GitLeaks tatsächlich, was übersieht es still, und was tun wir damit?
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.
Software Composition Analysis kümmert sich um die Bibliotheken, die du einbindest. Aber was ist mit dem Code, den dein Team selbst schreibt? Genau dafür ist Static Application Security Testing da. In Teil 5 unserer GitLab DevSecOps Serie integrieren Patrick Steger und ich SAST in die Pipeline, bauen ein paar realistische Schwachstellen in unser Spring-Boot-Beispiel ein und schauen zu, wie GitLab sie aufgreift.
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.
Dein Code ist der kleine Teil. Die Libraries, die du reinziehst, sind der grosse Teil — und genau dort steckt der Grossteil deiner CVEs. In Teil 3 der GitLab DevSecOps Serie bauen Patrick Steger und ich eine kleine Spring-Boot-Demo auf, hängen sie in eine GitLab-Pipeline und ergänzen anschliessend Software Composition Analysis mit einer einzigen Include-Zeile.
Bevor wir irgendwelche Security-Checks nach links verschieben können, brauchen wir ein Projekt, ein Repository und eine Pipeline, die tatsächlich etwas baut. In Teil 2 unserer GitLab DevSecOps Serie loggen sich Patrick Steger und ich in GitLab ein, legen ein neues .NET-Core-Projekt aus einem Template an und schauen uns die .gitlab-ci.yml an, die GitLab automatisch für uns generiert — inklusive Build- und Test-Job, die das Fundament für alles werden, was wir später ergänzen.
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.
Wie stellt man sicher, dass die eigene Organisation nicht mit zu vielen Projekten, zu vielen Ideen und zu wenig Fokus überlastet wird? Und wie stellt man sicher, dass man das Richtige baut? Genau dafür gibt es Epics. In diesem Video erkläre ich das Konzept der Epics, zeige ein konkretes Beispiel und erläutere, warum Epics deutlich effektiver sind als traditionelle Projekte.
In meinem letzten Video haben wir uns angeschaut, was ein Backlog ist. Dabei haben wir gelernt, dass ein Backlog aus Product Backlog Items besteht, kurz PBI. In diesem Video gehen wir eine Ebene tiefer und schauen uns an, was genau ein PBI ist, wie es sich über die Zeit entwickelt und wie es mit dem Product Backlog, dem Sprint Backlog und dem Product Owner zusammenhängt.
