Nach elf Sessions, in denen wir eine komplette DevSecOps-Pipeline mit GitLab aufgebaut haben — von Software Composition Analysis über Container Scanning, SAST, Secret Detection und DAST bis hin zu Merge Request Integration und Scheduled Pipelines — schliessen Patrick Steger und ich die Serie mit unseren Empfehlungen ab. Was funktioniert, wo es Stolpersteine gab und was wir jedem mitgeben würden, der heute die gleiche Pipeline aufbauen will.
Was wir gebaut haben und was geblieben ist#
Kurzer Rückblick: Wir haben mit zwei Einführungsvideos zu GitLab und Projekt-Setup begonnen, dann Software Composition Analysis ergänzt, um Schwachstellen in Abhängigkeiten zu finden, License Compliance, um Lizenzprobleme zu flaggen, Static Application Security Testing für den eigenen Code, Container Scanning, Secret Detection, um versehentlich committete Passwörter abzufangen, Dynamic Application Security Testing als automatisierten Penetration Test gegen die laufende Anwendung, Merge Request Integration, sodass die Security-Auswirkung von Änderungen sichtbar ist, bevor sie landen, und schliesslich Scheduled Pipelines, damit Produktionscode regelmässig gegen neu bekannt gewordene Schwachstellen geprüft wird.
Das sind viele bewegliche Teile. Hier sind die Punkte, auf die wir wirklich Wert legen würden.
Default Branch sauber definieren#
Der Default Branch ist der Branch, den GitLab für das Vulnerability Management verwendet. Dort tauchen alle Ergebnisse der Security-Tools auf. Definiere ihn am Anfang des Projekts sauber, denn alles andere — Merge-Request-Gates, geplante Scans, das Vulnerability Dashboard — hängt daran.
Scheduled Pipelines gegen Produktionscode#
Deine Anwendung läuft lange nach dem letzten Commit weiter in Produktion. Schwachstellen in Abhängigkeiten, Base Images und Frameworks werden täglich neu bekannt. Wenn deine Pipeline nur bei Code-Änderungen läuft, übersiehst du sie. Scheduled Pipelines führen deine Security-Tests in regelmässigem Rhythmus gegen den Produktionscode aus, sodass du neue Schwachstellen findest, sobald sie bekannt werden. Das ist nicht optional — es ist der einzige Weg, aktuell zu bleiben.
Merge Requests als Security-Gate#
Wenn Code in den Default Branch übernommen wird, immer über einen Merge Request. Die Pipeline läuft, und neu eingeführte Security-Probleme werden direkt neben der Änderung sichtbar, die sie verursacht hat. Definiere, welche Approver neue Findings akzeptieren dürfen — Security-Findings sollten nicht still von dem durchgewunken werden, der gerade online ist. Eine klare Approval-Regel hält die Latte ehrlich.
Niemals Secrets im Source Code#
Secret Detection existiert, weil jedes Team irgendwann versehentlich ein Credential committet. Lass es bei jedem Commit laufen, sodass dieser Fehler sofort auffällt — nicht erst Wochen später, wenn jemand das öffentliche Repo scraped. Und leg deine Secrets in einen Vault. GitLab integriert sich gut mit HashiCorp Vault, und das ist unsere Empfehlung. Source Code ist für Code; Secrets gehören in einen Secret Store.
Out-of-the-Box ist einfacher — eigene Tools sind echter Aufwand#
GitLab liefert ein Default-Set an Security-Scannern mit, und das ist der Weg des geringsten Widerstands: einfache Integration, geringer Wartungsaufwand, vorhersagbare Updates. Wenn du eigene Tools mitbringst, plane signifikanten Integrations- und Wartungsaufwand ein. Eine Ausnahme verdient einen besonderen Hinweis: DAST. Auch mit dem GitLab-eigenen DAST-Scanner musst du customizen. Eine out-of-the-box DAST-Konfiguration liefert sehr begrenzte Ergebnisse, weil der Scanner nicht weiss, wie er sich authentifizieren soll, wo er crawlen soll oder welche Eingaben er ausprobieren soll. Plane Zeit für diese Customization ein. Das ist der Unterschied zwischen einem echten Penetration Test und einem Häkchen auf der Checkliste.
Hol einen Security-Experten ins Team#
Eine DevSecOps-Pipeline ist tatsächlich komplex. Viele Tools, viele Konfigurationen, viele Findings, die triagiert werden müssen. Wir empfehlen dringend, einen Security-Experten von Anfang an einzubinden — jemanden, der hilft zu entscheiden, welche Tools verwendet werden, wie sie konfiguriert werden, worauf gegated wird und wie das resultierende Vulnerability Backlog gemanagt wird. Ohne diese Expertise wird die Pipeline entweder zu laut und ignoriert oder zu lax und nutzlos.
Key Takeaways#
Default Branch bewusst setzen. Er ist der Anker für Vulnerability Management und jedes Gate stromabwärts. Mach das richtig, bevor du irgendetwas anderes verdrahtest.
Scheduled Pipelines schützen Produktionscode. Schwachstellen werden täglich bekannt; deine Pipeline darf nicht nur bei Commits laufen. Plane sie ein.
Merge Requests sind der Ort für Security-Gates. Neuer Code in den Default Branch geht über einen Merge Request, die Pipeline läuft, und Approver entscheiden, was akzeptiert wird.
Secrets gehören nie in den Source Code. Secret Detection bei jedem Commit, Secrets in einem Vault — HashiCorp Vault integriert sich sauber mit GitLab.
Out-of-the-Box-Scanner sparen Wochen. Eigene Tools sind möglich, aber teuer. Die Ausnahme: Auch GitLabs eigenes DAST braucht ernsthafte Customization, um nützliche Ergebnisse zu liefern.
Du brauchst einen Security-Experten im Team. Das Tooling ist der einfache Teil. Zu wissen, worauf zu gaten, was zu ignorieren und wie das Vulnerability Backlog zu managen ist, braucht echte Expertise — hol sie früh dazu.