Stellen Sie sich eine Welt vor, in der Sicherheit nahtlos in Ihren Entwicklungsworkflow integriert ist, von der Idee bis zur Produktion, sodass sich Entwicklungsteams vollständig auf die Feature-Entwicklung konzentrieren können und dabei sichere Anwendungen bauen. Genau das habe ich am OWASP Chapter Meetup Schweiz präsentiert. In diesem Vortrag zeige ich, wie Platform Engineering die moderne Anwendungssicherheit transformiert und DevSecOps im grossen Massstab zur Realität macht.
Sicherheit ist in der modernen Softwareentwicklung kein nachträglicher Gedanke mehr. Sie muss nahtlos in jede Phase des Entwicklungszyklus integriert werden. Dieser Vortrag befasst sich mit der transformativen Kraft der Kombination von DevSecOps-Prinzipien mit Platform Engineering, um die Herausforderungen kontinuierlicher Sicherheit in einer schnelllebigen, agilen Umgebung zu bewältigen.
An der Conf42 DevSecOps 2024 Konferenz habe ich meinen Ansatz zur Architektur für Continuous Delivery vorgestellt. Nach über 21 Jahren bei Zühlke, in denen ich branchenübergreifend an DevOps-Transformationen gearbeitet habe, sehe ich immer wieder dasselbe fundamentale Problem: Wertströme, die durch Mauern der Verwirrung gebrochen werden. In diesem Vortrag zeige ich, wie Organisationen den Weg von Projekt-Denken zu Produkt-Denken schaffen, Qualität und Sicherheit von Anfang an einbauen, für Betreibbarkeit architekturieren und Platform Engineering zur Skalierung nutzen können.
Nach elf Sessions, in denen wir eine komplette DevSecOps-Pipeline mit GitHub aufgebaut haben — Software Composition Analysis, License Compliance, SAST, Container Scanning, Secret Detection, DAST, Pull Requests, Scheduled Pipelines und Vulnerability Management — schliessen Patrick Steger und ich die Serie mit unseren Empfehlungen ab. Was auf GitHub funktioniert, wo die Lücken sind und was wir jedem mitgeben würden, der die gleiche Pipeline bauen will.
Über zehn Sessions haben wir Security-Checks in eine GitHub-Actions-Pipeline verdrahtet, die auf jedem Commit und jedem Pull Request feuert. Das deckt den Code ab, an dem wir aktiv arbeiten. Es deckt nicht den Code ab, der bereits in Produktion läuft, während Researcher laufend neue CVEs in den Libraries finden, die er nutzt. In Teil 11 der GitHub DevSecOps Serie bauen Patrick Steger und ich einen Scheduled Workflow, der den Production-Branch erneut scannt — und stossen dabei auf eine GitHub-Limitierung, die man von Anfang an kennen sollte.
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.
Wir haben in den letzten acht Sessions Scanner in unsere GitHub DevSecOps Pipeline eingebaut — SCA, SAST, Container Scanning, Secret Detection, DAST. Die Scanner produzieren jetzt einen kontinuierlichen Strom von Findings, und die Frage lautet: Wo managen wir sie? In Teil 9 schauen Patrick Steger und ich uns das eingebaute Vulnerability Management von GitHub an — den Security Tab — und benennen, was funktioniert und was fehlt.
Nach sieben Sessions statischer Analyse — SCA, License Compliance, SAST, Container Scanning, Secret Detection — wechseln Patrick Steger und ich auf die dynamische Seite der Pipeline. In Teil 8 ergänzen wir Dynamic Application Security Testing in unserer GitHub-Actions-Pipeline. DAST startet die Anwendung und greift sie dann an. GitHub liefert das nicht out of the box, also bauen wir eine Community-Action auf Basis von OWASP ZAP ein — und sind ehrlich, wo dieser Ansatz für Enterprise-Use an Grenzen stösst.
API-Keys, Tokens und Passwörter rutschen nach wie vor regelmässig in Repositories — manchmal aus Versehen, manchmal weil Entwickler es ehrlich nicht besser wussten. In Teil 7 unserer GitHub DevSecOps Serie schalten Patrick Steger und ich GitHubs eingebautes Secret Scanning ein, definieren ein eigenes Pattern, probieren Push Protection aus und schauen offen hin, wo die Funktion liefert und wo sie noch nicht hält, was sie verspricht.
Wir haben die GitHub-Actions-Pipeline in fünf Sessions aufgebaut: Projekt-Grundlagen, Software Composition Analysis, License Compliance und Static Application Security Testing. Die nächste Schicht ist Container Scanning — die Suche nach Schwachstellen im Docker-Image, das wir ausliefern, nicht nur im Source, den wir geschrieben haben. In Teil 6 unserer Serie teilen Patrick Steger und ich die Arbeit in zwei GitHub-Actions-Sub-Workflows auf: einer baut das Image und pusht es in die Registry, der andere zieht es zurück und lässt Trivy darauf laufen.
SCA hat unsere Dependencies abgedeckt. License Compliance hat geklärt, was wir ausliefern dürfen. SAST ist die Stelle, an der wir die Scanner auf den Code richten, den wir selbst geschrieben haben. In Teil 5 unserer GitHub DevSecOps Serie integrieren Patrick Steger und ich Static Application Security Testing in die Pipeline — und merken auf die harte Tour, dass es auf GitHub drei Actions braucht statt einer.
GitHub liefert von Haus aus keinen License Scanner mit, und als wir im Marketplace gesucht haben, hat keine der vorhandenen Actions getan, was wir brauchten. Also haben wir mit einem Kollegen von Microsoft eine eigene gebaut und veröffentlicht. In Teil 4 unserer GitHub DevSecOps Serie binden Patrick Steger und ich diese License-Finder-Action in unsere Spring-Boot-Pipeline ein, konfigurieren die erlaubten Lizenzen und zeigen, wie man die Resultate in GitHub sichtbar macht.
