Was definiert hochwertige Arbeit in der Softwareentwicklung? Ist es Scrum? Clean Code? TDD? Funktionale Programmierung? In dieser Expert Talks Session präsentieren mein Kollege Milan und ich zwei komplementäre Perspektiven. Milan behandelt die Säulen hochwertiger Engineering-Arbeit, von Teambildung und Kundenzentrierung bis zu Clean Code und Engineering-Kultur. Ich zeige dann, wie DevOps und Continuous Delivery helfen, grossartige Produkte zu bauen, indem man vom Projekt-Mindset zum Produkt-Mindset wechselt.
In jedem Projekt, jedem Unternehmen, jeder Abteilung wird ein Game of Thrones gespielt. Machtspiele zwischen Menschen, Teams und Abteilungen, die zu massiven Konflikten führen. In diesem Vortrag zeige ich, warum diese Konflikte existieren, welche Strategien man nutzen kann, um sie zu überleben, und wie man in schwierigen Zeiten gesund bleibt. Das Game of Thrones wird überall gespielt. Es beginnt im Kindergarten mit dem Kampf um eine Puppe und endet auf dem Sterbebett, wenn Nachkommen um das Erbe kämpfen.
Ich wurde eingeladen, die Keynote am Baloise OpenX Day zu halten, einer internen Konferenz, an der die Baloise ihre Technologie-Community zusammenbringt. Die Session kombinierte Impulsvorträge mit interaktiven Diskussionen und gab mir die Gelegenheit, DevOps-Grundlagen zu teilen und dann direkt von den Teams über ihre echten Herausforderungen zu hören. Die Gespräche mit den Baloise-Ingenieuren waren unglaublich wertvoll, besonders zu Themen wie Continuous Deployment in regulierten Branchen und die Rolle von Platform Engineering.
Nach elf Sessions, in denen wir eine komplette DevSecOps-Pipeline mit GitLab aufgebaut haben — von Software Composition Analysis über Container Scanning, SAST, Secret Detection und DAST bis hin zu Merge Request Integration und Scheduled Pipelines — schliessen Patrick Steger und ich die Serie mit unseren Empfehlungen ab. Was funktioniert, wo es Stolpersteine gab und was wir jedem mitgeben würden, der heute die gleiche Pipeline aufbauen will.
In zehn Sessions haben wir sechs Security-Tools in eine GitLab-Pipeline verdrahtet, die auf jedem Commit und jedem Merge Request feuert. Sind wir damit fertig? Nicht ganz. Code, der in Produktion läuft, bleibt dort Wochen oder Monate liegen, und in dieser Zeit finden Security-Researcher laufend neue CVEs in genau den Dependencies, die du längst ausgeliefert hast. In Teil 11 der GitLab DevSecOps Serie bauen Patrick Steger und ich eine Scheduled Pipeline, die den Production-Branch automatisch erneut scannt — ohne dass jemand pushen muss.
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.
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.
