Scheduled Pipelines

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