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.
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.
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.
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.
Bevor wir Security-Tools an irgendetwas anschliessen, brauchen wir ein Repository, eine Pipeline und einen lauffähigen Build. In Teil 2 unserer GitHub DevSecOps Serie legen Patrick Steger und ich ein privates GitHub-Repo für einen kleinen Java-Spring-Boot-Service an, aktivieren GitHub Actions und verdrahten eine Pipeline aus zwei Workflows, die den Code kompiliert und die Unit Tests ausführt. Das ist das Skelett, an dem in der Serie alles Weitere hängt.
