SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 7: Lizenzchecks

Grundsätzlich beinhaltet die SBOM auch Lizenzinformationen. Das gilt sowohl für die durch die SBOM beschriebene Komponente selbst, aber insbesondere auch für deren zahlreiche Abhängigkeiten.

Speziell bei der Verwendung von Open-Source-Abhängigkeiten mit ihren verschiedensten, möglichen Lizenzen liegt es so nahe, die SBOM auch als Basis für ein Reporting oder einen Check auf gewollte, kompatible (Whitelist) oder im Unternehmen verbotene Lizenzen (Blacklist) zu nutzen und damit ein ggf. bereits bestehendes Tooling zur Lizenzprüfung abzulösen.

Welche Werkzeuge für Lizenzchecks oder Reportings aus unserer Sicht geeignet sind und was diese genau können, haben wir uns daher für diesen Beitrag genauer angesehen.

Du bist neu dabei? Hier kannst du einen Blick in die ersten sechs Teile der Blogserie werfen:

• Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken
• Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten
• Teil 3: SBOM-Formate im Vergleich – CycloneDX versus SPDX
• Teil 4: Was ist eine gute SBOM – Das Versuchssetting
• Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich
• Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?

Kriterien für die Lizenzauswertung

Für ein Reporting sind aus unserer Sicht drei Kriterien relevant:

1. Vollständigkeit: Hier fokussieren wir uns erst einmal auf die Softwarekomponenten und ignorieren OS, Packages o. ä. Wir verzichten an dieser Stelle auch auf Hashes und Fingerprints oder den Abgleich gegen eine zentrale Datenbank.
2. Sprache: Der Report sollte auch in deutscher Sprache bereitgestellt werden können. In der Praxis ist dies am einfachsten zu realisieren, wenn das Template für einen Report selbst erstellt werden kann.
3. Konfigurierbarkeit:
   – Die angezeigten Attribute, die Sortierung sowie die allgemeine Darstellung sollten konfigurierbar sein.
   – Bei kombinierten Java- und Angular-Projekten ist es relevant anzuzeigen, ob es sich um ein Maven- oder NPM-Artefakt handelt.
   – Auch die GroupId hilft, das Artefakt besser einzuordnen.
   – Ggf. kann zusätzlich eine Beschreibung des Artefakts in der SBOM angezeigt werden.
   – Schließlich wäre es gut, wenn man auf die Sortierung Einfluss nehmen könnte.
   – Ist der Report nicht konfigurierbar, sollte dieser dennoch sinnvoll auswertbar und auch für Nicht-Techniker verständlich sein.

Für eine Prüfung der Lizenzen gegen eine Whitelist oder Blacklist ergeben sich weitere Anforderungen:

• Grundsätzlich muss es möglich sein, entsprechende White- oder Blacklists überhaupt definieren zu können. Am besten wäre es, wenn diese Definition zentral erfolgt. So läßt sich vermeiden, dass in einzelnen Projekten mit einer älteren oder anderen Version der Liste gearbeitet wird.
• Hierzu gehört auch die Möglichkeit, organisatorische Prozesse auf diese Liste(n) abzubilden, um beispielsweise Änderungen protokollieren zu können. Hierfür reicht im einfachsten Fall die Verwendung von Textdateien in einem Git-Repository aus.
• Wichtig ist auch die Möglichkeit, manuell nicht-SPDX-konforme Lizenzangaben nach der Prüfung korrigieren zu können.
• Ebenso ist es hilfreich, wenn man zu einer Lizenz-Expression (z. B. „MIT OR BSD-2-Clause“) definieren kann, welche der möglichen Lizenzoptionen gewählt wurde. Diese Auswahl kann – muss aber nicht – auch automatisch geschehen.

Welche SBOM-Werkzeuge haben wir untersucht?

Zu den genannten Kriterien haben wir uns diese Werkzeuge angeschaut:

Hinweis: Grundsätzlich existieren weitere Werkzeuge zum Reporting oder zur Prüfung der verwendeten Lizenz. Beispiele hierfür sind u. a. Sonarqube Licensecheck, der Gradle-License-Report, der NPM License Checker, die Möglichkeiten der Maven Site oder auch das License Maven Plugin. Diese Werkzeuge wurden hier nicht betrachtet, weil sie nicht auf Basis einer SBOM arbeiten.

Kein Werkzeug überzeugte zu hundert Prozent

Um es vorwegzunehmen: Keines der betrachteten Werkzeuge konnte uns völlig überzeugen. Im Bereich Reporting sind sbomgr, sbom-utility sowie sbom2doc Werkzeuge, die man sich anschauen kann, aber auch aus unserer Sicht aktuell offensichtliche Mängel haben. Alternativ sind manuelle Auswertungen auf Basis jq möglich. Im Bereich der Prüfung ist der Einsatz von Dependency Track vermutlich noch am sinnvollsten – mit entsprechend großem Setup-Aufwand.

Wer bereits jQAssistant nutzt, ist mit der Integration vertraut und kann hiermit bzgl. Reporting als auch Prüfung grundsätzlich viele der Anforderungen schnell und elegant umsetzen. Wer jQAssistant noch nicht nutzt, muss sich hierzu allerdings erst in jQAssistant einarbeiten (was es aus Sicht der Autoren grundsätzlich wert ist) und sollte es auch für seinen eigentlichen Zweck („Software Analytics“ und „Living Documentation“) nutzen wollen.

Die Ergebnisse

Hier die detaillierteren Erkenntnisse zu den einzelnen Werkzeugen:

• sbomgr: Grundsätzlich ist ein Text-Report erzeugbar. Die Form des Reports erlaubt allerdings keine einfache, automatisierte Auswertung. Es gibt kein Templating.
• jqassistant-cyclonedx-plugin: Siehe oben. Prozesse müssen auf Basis von jQAssistant realisiert werden. Reporting würde man auf Basis Asciidoc realisieren. Ein Abgleich gegen eine Whitelist oder Blacklist ist grundsätzlich möglich. Eine automatische Auswertung von Lizenz-Expressions würde die Möglichkeiten von jQAssistant vermutlich überschreiten.
• sbom-utility: Ein Report kann erzeugt werden. Uns gefällt aber die Darstellung nicht (Auswertbarkeit). Es gibt kein Templating. Bzgl. einer Überprüfung können Lizenzen kategorisiert werden. Die Kategorisierung ist schön, hat aber den entscheidenden Nachteil, dass sbom-utility keine entsprechenden Return-Codes erzeugt oder die Verarbeitung abbricht. Für einen Check müsste daher der Report noch selbst manuell ausgewertet werden.
• jq: Wir waren mit etwas Aufwand in der Lage, mittels jq eine neue JSON-Datei auf Basis einer CycloneDX SBOM mit den für einen Report relevanten Rohdaten zu erzeugen. Ein weiterführendes Reporting oder Überprüfung müsste dann auf Basis dieser neuen Datei mit eigenen Mitteln erzeugt werden.
• mdBOM: Hier ist grundsätzlich ein Templating möglich, allerdings wird die SBOM „von Hand“ nach nur einer kleinen Untermenge von Attributen geparsed. Wir haben das Tool daher nicht weiter betrachtet.
• sbom2doc: Hier sind die Reports grundsätzlich ansehnlich, aber in keiner Weise beeinflussbar. Für unsere Zwecke wären es aber notwendig, sie inhaltlich anzupassen. Das PDF-Ergebnis scheint fehlerhaft.
• License Compliance Tool: Grundsätzlich scheint das Tool gut zu sein, es ist allerdings für einen anderen Zweck (Aggregation von Lizenztexten) erstellt worden. Ein Tailoring für unsere Zwecke scheint nicht so einfach möglich zu sein.
• license-checker-cyclonedx-maven-plugin: Grundsätzlich interessant. Leider scheint dieses Tool aber nicht mehr weiterentwickelt zu werden. Auch ist es sehr auf Maven zugeschnitten, so dass sich in der Praxis schnell integrative Probleme ergeben.
• Dependency Track: Unterstützt grundsätzlich viele unsere Anforderungen (Reporting-Sichten sowie die Möglichkeit Policies für Lizenzen zu definieren) und auch vieles mehr – ist aber in dem Sinne keine Lösung für eine einfache Integration im CI Build und kommt mit dem entsprechenden Setup-Kosten daher.

Fazit und Empfehlung

Im Summe sehen wir sinnvolle und pragmatische und vermutlich auch völlig ausreichende Ansätze in den einzelnen Werkzeugen. Wie schon erwähnt, fehlt uns das eine Werkzeug, das alles in entsprechender Qualität kann. Es sein denn, wir bauen auf jQAssistant oder Dependency Track auf, die aber entsprechende Einarbeitungs- und Setup-Kosten mit sich bringen.

Pragmatisch & einfach

Allen, die hohe Kosten und Aufwand vermeiden wollen, empfehlen wir einfache, pragmatische Ansätze, um z. B. mittels jq Input für ein Reportingwerkzeug oder für einen einfachen automatisierten Abgleich zu erzeugen.

Herausfordernd & mehr Möglichkeiten

Wer die Herausforderung annimmt, wagt sich für eine automatische Bearbeitung evtl. an License-Expressions. Hiermit muss in der Praxis ein pragmatischer Umgang gefunden werden.

Blick in die Zukunft

Wir vermuten, dass der aktuelle, ernüchternde Status im Bereich Lizenzreporting und -check etwas damit zu tun hat, dass es für die Lizenzprüfung bereits Werkzeuge gibt, die zwar nicht auf der SBOM arbeiten, dafür aber bereits länger existieren und daher schon – mit ausreichender Zufriedenheit – entsprechend verbreitet sind.

Hier wäre im Einzelfall zu entscheiden, ob wir mit einem potenziellen Delta zwischen dieser Prüfung und den Informationen in einer SBOM leben können oder längerfristig doch auf die SBOM umschwenken, die ja zukünftig ein Auslieferungsgegenstand sein könnte.

Besteht die Möglichkeit, schnell zu einer leichtgewichtigen und akzeptablen Lösung zu kommen, kann der Schwenk frühzeitig durchgeführt werden. Ansonsten empfehlen wir, abzuwarten und das Werkzeugangebot weiter zu beobachten!

Wie geht es weiter?

Im nächsten Teil geht es um die Frage, wie wir SBOMs in den Software-Development-Prozess eingliedern können.

Danach geht es weiter mit Fragen wie diesen:

• Was ist beim Start in die SBOM-Welt zu beachten?
• Was ist von den Konzepten hinter SBOM zu halten?
• Summary und Tipps für den Start

Bisherige Teile ansehen:

Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken

Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten

Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX

Teil 4: Was ist eine gute SBOM? – Das Versuchssetting

Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich

Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?