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.
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.
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.
