GitHub liefert von Haus aus keinen License Scanner mit, und als wir im Marketplace gesucht haben, hat keine der vorhandenen Actions getan, was wir brauchten. Also haben wir mit einem Kollegen von Microsoft eine eigene gebaut und veröffentlicht. In Teil 4 unserer GitHub DevSecOps Serie binden Patrick Steger und ich diese License-Finder-Action in unsere Spring-Boot-Pipeline ein, konfigurieren die erlaubten Lizenzen und zeigen, wie man die Resultate in GitHub sichtbar macht.
Warum License Compliance — auch in einem “einfachen” Projekt#
Patrick antwortet wie schon bei der Software Composition Analysis. Unser Java-Programm verwendet Spring Boot, und Spring Boot zieht dutzende Bibliotheken anderer Anbieter rein. Jede dieser Bibliotheken kommt mit einer Lizenz, und Lizenzen kommen mit Regeln — was du tun darfst, was nicht, was du offenlegen musst. Um konform zu bleiben, musst du wissen, was du verwendest, und entscheiden, welche Lizenzen du akzeptierst. Genau das gibt dir License Compliance.
Wie wir zur License-Finder-Action kamen#
GitHub bietet keinen eingebauten License Scanner. Der Weg ist derselbe wie bei SCA: nimm etwas aus dem Marketplace. Das Problem war, dass nichts im Marketplace gepasst hat. Zusammen mit unserem Kollegen Juan Manuel von Microsoft haben wir eine GitHub Action geschrieben, die das Open-Source-Projekt Pivotal License Finder kapselt. Sie ist im Marketplace unter dem Namen License Finder veröffentlicht — und genau die nutzen wir hier. Wichtig vorweg: Die Action ist aktuell im Alpha-Status, und es gibt keinen einfachen In-UI-View für alle verwendeten Lizenzen — die stehen im Log-Output der Action.
Wie die Action funktioniert#
Sobald sie im Workflow ist, ist der Ablauf geradlinig. Die Action scannt jede Abhängigkeit deines Projekts, sucht nach der License-Datei, vergleicht jede Lizenz mit einer konfigurierten Liste erlaubter Lizenzen, meldet nicht-konforme Lizenzen als Test Results in der GitHub-UI und lässt den Build scheitern, sobald eine Lizenz ausserhalb der Allow-Liste auftaucht. Letzteres macht aus dem Ganzen ein echtes Gate und nicht nur einen passiven Report.
Ein Sub-Workflow, kein Schritt im Main-Workflow#
Statt License Compliance an die Hauptpipeline zu schrauben, fügen wir sie als separaten Sub-Workflow hinzu. Wir definieren eine neue Workflow-Datei namens License Compliance und triggern sie aus der Hauptpipeline (oder optional manuell). Der Job checkt den Code aus und führt die License-Finder-Action aus. Ein kleiner Fix ist nötig: Du musst die Maven-Datei vor dem Lauf entfernen, sonst startet License Finder nicht sauber.
Erlaubte Lizenzen konfigurieren#
Die Action nimmt zwei zentrale Parameter. permitted-licenses ist die Liste der Lizenzen, die du akzeptierst — für die Demo haben wir mit MIT und Apache-2.0 begonnen, damit wir bewusst Findings bekommen. approved-dependencies ist die Liste an Bibliotheken, die ohne License-Datei kommen, die du aber als okay erklärt hast. Der Einfachheit halber haben wir alle Spring-Boot-Abhängigkeiten ohne License-Datei in diese Liste aufgenommen. In einem realen Projekt verdient diese Entscheidung mehr Sorgfalt.
Resultate in GitHub sichtbar machen#
License Finder erzeugt eine Unit-Test-Report-Datei. Die füttern wir in die publish-unit-test-result-Action — dieselbe wie in den vorherigen Sessions — mit einem kleinen Twist: Wir benennen den Report in License Compliance Check um, damit er in der GitHub-UI auch unter diesem Namen erscheint und nicht als generisches Test-Ergebnis. Zusätzlich laden wir den vollständigen Report als Artifact hoch, sodass jeder das Rohergebnis als Zip herunterladen kann.
Was der erste Lauf zeigte#
Die Pipeline lief, der License Compliance Check tauchte im Workflow auf, und der Check meldete: 55 Bibliotheken gefunden — fünf davon mit Lizenzen ausserhalb unserer Allow-Liste. Im Raw-Output sahen wir eine Bibliothek mit BSD-Lizenz, eine mit CDDL + GPLv2 und drei mit Eclipse Public License 1.0. Keine davon ist für unseren Use Case problematisch, also haben wir sie in die Allow-Liste aufgenommen. Nach einem erneuten Lauf war der Check grün und alle 55 Bibliotheken durch.
Wer entscheidet, was akzeptabel ist?#
Ich habe Patrick die naheliegende Frage gestellt: Wer entscheidet eigentlich, welche Lizenzen in die Allow-Liste kommen? Seine Antwort: kommt drauf an. In manchen Organisationen liegt die Policy bei einer zentralen Architektur- oder Security-Abteilung. In anderen bleibt sie beim Projekt — typischerweise beim Tech Lead, der auch eine Security-Risk-Liste pflegt. Das Tool beantwortet die Frage nicht für dich. Es setzt nur durch, was du konfigurierst — also sorg dafür, dass jemand die Policy verantwortet.
Was diese Pipeline dir bringt#
GitHub liefert License Compliance nicht out of the box, aber mit der License-Finder-Action plus einem kleinen Wrapper-Sub-Workflow bekommst du einen Scanner, der bei jeder Pipeline läuft, den Build bei nicht erlaubten Lizenzen scheitern lässt, Resultate als Check in GitHub anzeigt und den Raw-Report zum Download anbietet. Verglichen mit dem GitLab-Template ist das mehr Setup — das Resultat ist dasselbe: eine Lizenzfrage, die bei jedem Commit automatisch beantwortet wird.
Key Takeaways#
GitHub hat keinen eingebauten License Scanner. Du landest im Marketplace. Wenn dort nichts passt, schreibst du eine eigene Action — genau so ist die License-Finder-Action entstanden, die wir hier verwenden.
Lauf als Sub-Workflow. License Compliance in einer eigenen Workflow-Datei zu halten, macht es einfach, ihn wiederzuverwenden, manuell zu triggern und unabhängig vom Main Build zu denken.
permitted-licensesundapproved-dependenciesmachen Unterschiedliches. Das eine ist die Policy für Lizenzen, die du akzeptierst; das andere fängt Bibliotheken ab, die ganz ohne License-Datei kommen. Beides bewusst behandeln.Benenne den Test-Report um. Den Output über die Unit-Test-Action zu publishen, macht ihn in der UI sichtbar — aber nur, wenn du ihm einen sinnvollen Namen gibst. Sonst geht er in den “Test Result”-Einträgen unter.
Die Policy braucht einen Owner. Tooling setzt die Allow-Liste durch; es entscheidet nicht, was reingehört. Wähl die Rolle — zentrale Security, zentrale Architektur, Tech Lead — und mach die Verantwortung explizit.
Achte auf die Alpha-Caveats. Unsere Action ist im Alpha-Status, und es gibt keinen schönen “alle Lizenzen”-View in GitHub — du musst ins Log schauen. Plan das ein, lass dich nicht davon überraschen.