Du lieferst eine Java-Anwendung aus, die von Spring Boot abhängt, das wiederum von dutzenden weiteren Bibliotheken abhängt — jede mit ihrer eigenen Lizenz. Und die meisten Teams können dir nicht sagen, welche Lizenzen das eigentlich sind. In Teil 4 unserer GitLab DevSecOps Serie ergänzen Patrick Steger und ich die Pipeline um License Compliance, sodass diese Frage bei jedem Commit automatisch beantwortet wird. Die gute Nachricht: Mit GitLab Ultimate ist das eine Template-Zeile.
Warum ein Java-Projekt License Compliance braucht#
Patrick erklärt es genauso wie bei der Software Composition Analysis. Wir ziehen eine lange Liste an Bibliotheken in eine simple Spring-Boot-App, und jede einzelne kommt mit ihrer eigenen Lizenz. Manche sind freundlich, manche restriktiv, manche schlicht gefährlich für ein kommerzielles Produkt. Jede Lizenz von Hand zu lesen ist nicht realistisch — und selbst wenn du es einmal tust, ändert sich der Dependency-Graph beim nächsten Versions-Bump. Du brauchst ein Tool, das dir sagt, was du verwendest, und das dich entscheiden lässt, was akzeptabel ist.
Was License Compliance in GitLab macht#
License Compliance ist ein GitLab-Ultimate-Feature. Der Job geht durch alle Abhängigkeiten deines Projekts, leitet die Lizenz für jede ab, vergleicht das Ergebnis mit den Lizenzen, die du als akzeptabel markiert hast, und meldet alles, was nicht konform ist. Unter der Haube nutzt GitLab das Open-Source-Tool License Finder. Du konfigurierst nicht den Scanner, sondern die Policy.
Aktivierung in .gitlab-ci.yml#
Den Scan zu aktivieren funktioniert wie bei der Dependency Analysis: Du bindest das von GitLab bereitgestellte Template in .gitlab-ci.yml ein. In diesem Fall heisst das Template License-Scanning.gitlab-ci.yml. Include hinzufügen, committen — und der nächste Pipeline-Run hat einen neuen License-Scanning-Job. Wenn du die Scanner-Version pinnen willst, kopierst du das Template in dein eigenes Repo und referenzierst es von dort. Gleicher Trick wie zuvor.
Der Maven-Bug, den wir hatten#
Beim ersten Lauf scheiterte der Job in Zeile 41 mit LicenseFinder::Maven is not installed. Das Image, das GitLab zum Aufnahmezeitpunkt ausgeliefert hatte, hatte einen Bug — Maven war im Container vorhanden, aber nicht als ausführbar markiert. Der Fix sind fünf Zeilen am Anfang der Pipeline, die Maven als executable markieren. Damit lief der Job sauber durch. Merkenswert: Wenn ein managed Scanner plötzlich kaputt geht, liegt es fast nie an deinem YAML — schau zuerst auf das Upstream-Image.
Wo die Resultate landen#
Die Resultate erscheinen an zwei Orten. In der Pipeline gibt es einen neuen Licenses-Tab. Auf Projektebene findest du den vollständigen Bericht unter Security & Compliance → License Compliance. In unserem Spring-Boot-Demo waren wir überrascht, fünf verschiedene Lizenzen zu sehen — für ein Projekt, das ausser Spring Boot kaum etwas einbindet. Schon allein diese Sichtbarkeit ist den Setup-Aufwand wert. Die meisten Teams haben keine Ahnung, mit wie vielen Lizenzen sie ausliefern.
Die Policy definieren#
Unter License Compliance → Policies → Add license policy markierst du jede Lizenz als allowed oder denied. Wir haben vier der fünf gefundenen Lizenzen erlaubt und eine bewusst ohne Entscheidung gelassen, um zu sehen, wie die Pipeline darauf reagiert. Der nächste Lauf meldete genau diese eine als “noch nicht akzeptiert” und die anderen vier als approved. In unserem Setup bricht die Pipeline darauf nicht standardmässig ab — das kann man zusätzlich verdrahten.
Approval-Workflow für neue Lizenzen#
GitLab unterstützt zusätzlich einen einfachen Approval-Workflow für noch nicht klassifizierte Lizenzen. Unter Approvals fügst du eine Approval-Regel hinzu und weist eine Gruppe als Approver zu — wir haben die Gruppe zuehlke-devsecops genommen, das waren damals Patrick und ich. Bringt ein Merge Request danach eine Abhängigkeit mit unklassifizierter Lizenz mit, braucht der Merge Request ein Approval von jemandem aus dieser Gruppe, bevor er gemergt werden kann. Der volle Effekt zeigt sich erst, wenn man mit Feature-Branches und Merge Requests arbeitet — das ist eine spätere Session — aber das Setup lohnt sich jetzt schon.
Was du dafür bekommst#
Für eine Zeile in der Pipeline (plus den temporären Maven-Fix) bekommst du eine vollständige Inventarliste jeder Lizenz, von der dein Projekt abhängt, ein UI zur Klassifizierung, einen Approval-Workflow für neue Lizenzen und einen License-Report bei jedem Pipeline-Run. Genau das ist der Sinn von Shift Left bei Compliance: aus einem manuellen, schmerzhaften End-of-Project-Krampf wird ein Check, der bei jedem Commit läuft und Probleme dann sichtbar macht, wenn sie noch günstig zu beheben sind.
Key Takeaways#
Du lieferst mehr Lizenzen aus, als du denkst. Ein blosses Spring-Boot-Demo zog fünf verschiedene Lizenzen rein. Bei einem realen Produkt rechne mit dutzenden. Ohne Scanner kann niemand im Team die Frage “welche Lizenzen liefern wir aus?” beantworten.
Template einbinden, Scan bekommen.
License-Scanning.gitlab-ci.ymlist ein Einzeiler. Der Scanner basiert auf License Finder — du musst ihn nicht selbst zusammenbauen.Die Policy ist wichtiger als das Tool. Scannen ist der einfache Teil. Zu entscheiden, welche Lizenzen für dein Geschäft akzeptabel sind — und wer das entscheiden darf — ist die eigentliche Arbeit.
Nutze den Approval-Workflow. Weise eine Gruppe als License Approver zu. Neue, unklassifizierte Lizenzen werden so zu einer bewussten Entscheidung in einem Merge Request — nicht zu etwas, das unbemerkt in Produktion rutscht.
Behalt das Upstream-Image im Auge. Wir hatten einen “Maven nicht ausführbar”-Bug im GitLab-Container. Wenn ein managed Scanner kaputt geht, vermute zuerst das Image, nicht deine Konfiguration.
Compliance gehört in die CI, nicht ans Release. Bei jedem Commit zu scannen heisst, eine neue Lizenz einmal zu klassifizieren — beim Erscheinen. Beim Release zu scannen heisst, in der Woche vor Go-live in Panik zu geraten.