# GitLab DevSecOps Teil 3: Software Composition Analysis mit Gemnasium > Teil 3 der GitLab DevSecOps Serie. Patrick Steger und ich erweitern die Pipeline um Software Composition Analysis mit dem GitLab-eigenen Gemnasium-Template, scannen eine Spring-Boot-Demo nach verwundbaren Abhängigkeiten und besprechen, wie man mit den Findings umgeht. - Date: 2022-08-17 - Source: https://romanoroth.com/de/blogs/gitlab-devsecops-sca/ - Tags: DevSecOps, GitLab, CI/CD, DevOps, SCA, Software Composition Analysis, Dependency Scanning, Vulnerability Management, Gemnasium 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.
## Das Demo-Projekt Damit SCA greifbar wird, brauchen wir etwas zum Scannen. Wir legen in GitLab ein neues Projekt aus dem Spring-Template an und nennen es `videodemo`. Was wir bekommen, ist eine minimale Spring-Boot-Anwendung: ein Web Service, der "Spring is here!" zurückgibt, ein Unit Test, der den Service aufruft und das Ergebnis prüft, und ein Maven Build mit einer `pom.xml`. Winzig — und genau das ist der Punkt. Die paar Zeilen, die wir geschrieben haben, ziehen Dutzende Dritt-Bibliotheken nach sich. ## Zuerst eine minimale Pipeline Bevor wir Security anfassen, brauchen wir eine Pipeline. Wir legen eine `.gitlab-ci.yml` in den Repo-Root mit zwei Jobs: `build` und `test`. Der Build-Job verwendet ein versioniertes Maven-Docker-Image, läuft im Default-Stage `build` und legt das resultierende JAR als Artefakt ab. Der Test-Job läuft im Default-Stage `test`, führt die Unit Tests aus und publiziert den Testreport, sodass GitLab ihn im UI rendern kann. Commit, Push, und GitLab startet den Run. Beide Jobs werden grün. Damit haben wir eine Baseline, auf die wir Security setzen können. ## Was SCA wirklich ist Software Composition Analysis — auch Dependency Scanning genannt — sucht in den Bibliotheken, die deine Anwendung nutzt, nach bekannten Schwachstellen. Der Scanner läuft den Dependency-Tree ab, gleicht jede Library und Version mit öffentlichen CVE-Datenbanken ab und meldet alles, wofür ein bekanntes Problem existiert. In GitLab ist SCA Teil der Ultimate-Edition und wird mit Gemnasium umgesetzt, einem Open-Source-Scanner, den GitLab gekauft hat und nun selbst pflegt. Warum brauchen wir das schon für so eine kleine Anwendung? Schau ins Build-Log. Eine Spring-Boot-App zieht eine lange Liste an JARs nach — Spring, Jackson, Tomcat, Logging, alles dabei. Dein Code ist eine dünne Schicht auf fremdem Code. Wenn eine dieser fremden Libraries ein CVE ausgeliefert hat, hast du es ebenfalls ausgeliefert. Das einzige, was hilft, ist scannen. ## SCA in die Pipeline einbauen Gemnasium zu aktivieren ist ein Einzeiler. Wir machen ein `include` auf das GitLab-Template `Security/Dependency-Scanning.gitlab-ci.yml`, committen und pushen. GitLab fügt im nächsten Pipeline-Run einen Job `gemnasium-maven-dependency_scanning` hinzu. Der zieht das Gemnasium-Image, läuft den Maven-Dependency-Tree ab und lädt die Findings als Pipeline-Artefakt hoch. Weil das Template Open Source ist, kannst du es bei Bedarf in dein eigenes Repo kopieren — Versionen pinnen, Regeln ändern, auf einem Zeitplan laufen lassen. Für die meisten Teams reicht das Include. ## Wo die Findings landen An zwei Orten. Erstens als JSON-Artefakt unter Pipelines → dein Run → Artifacts. Das kannst du in jedes bestehende Vulnerability-Management-System einspeisen. Zweitens hat GitLab eine eigene Vulnerability-Management-Ansicht unter Security & Compliance → Vulnerability Report. Gemnasium hat sie automatisch befüllt, sortiert nach Schweregrad. Der vollständige Management-Workflow (Triage, Dismiss, Verlinkung mit Issues) ist ein Ultimate-Feature und bekommt später in der Serie eine eigene Session. Der erste Scan auf unserem Spielzeugprojekt brachte 28 critical und 61 high Vulnerabilities zutage. Aus ein paar Zeilen Demo-Code. So sieht die Realität moderner Abhängigkeiten aus. ## Musst du alle beheben? Grundsätzlich ja — aber bleib pragmatisch. Patricks Empfehlung, die ich teile: nicht jedes CVE einzeln tief analysieren, ob es deinen Code-Pfad wirklich trifft. Diese Arbeit frisst mehr Zeit als ein Upgrade. Hebe zuerst alle Abhängigkeiten auf eine fixierte Version. Nur für die, die du nicht upgraden kannst — kein gepatchtes Release, oder das Upgrade bricht dich — machst du die tiefere Analyse. Danach entscheidest du über kompensierende Massnahmen oder dokumentierst das akzeptierte Risiko. Sinn von SCA in der CI ist es, das zur Routine zu machen, nicht zu einem Projekt. Jeder Commit wird gescannt. Neue CVEs werden beim nächsten Pipeline-Run gefangen. Die Kosten, aktuell zu bleiben, sind klein. Die Kosten, hinterherzuhinken, sind ein Panik-Upgrade unter Audit-Druck. ## Key Takeaways 1. **Der grösste Teil deines Codes ist nicht von dir.** Eine kleine Spring-Boot-Demo zieht Dutzende JARs. SCA ist für jede ernsthafte Anwendung nicht optional. 2. **GitLab macht SCA zum Einzeiler.** `include` auf das Template `Security/Dependency-Scanning.gitlab-ci.yml` — der Gemnasium-Job erscheint im nächsten Run. 3. **Findings liegen an zwei Orten.** JSON-Artefakt für dein eigenes Tooling und der eingebaute Vulnerability Report unter Security & Compliance für den GitLab-eigenen Workflow. 4. **Das Template ist Open Source.** Kopiere es ins Repo, wenn du pinnen, scheduleen oder anpassen willst. Das Default-Include reicht für die meisten Teams. 5. **Erst upgraden, dann analysieren.** Verbringe keine Stunden damit zu beweisen, dass ein CVE dich nicht trifft. Hebe auf eine fixierte Version. Spar dir die tiefe Analyse für die Abhängigkeiten, die wirklich nicht zu bewegen sind. 6. **SCA ist Ultimate-Tier bei GitLab.** Der Scanner läuft überall, aber die integrierte Vulnerability-Management-UI ist kostenpflichtig. Wisse, was du kaufst, bevor du dein Reporting darum herum baust.