Ü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.
GitHub liefert kein Default-SCA-Tool wie GitLab. Du musst zwei Dinge kombinieren: das Plattform-Feature Dependabot und eine SCA-Action aus dem Marketplace. In Teil 3 der GitHub DevSecOps Serie verdrahten Patrick Steger und ich beides in unsere Pipeline — und merken auf die harte Tour, dass der Marketplace-Pfad nicht so glatt läuft, wie es die Slides suggerieren.
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.
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.
