Bisquat2: Was versteckt sich denn da?

Heute beleuchten wir ein Thema, das nach wie vor als „kleine Schwester des Programmierens“ nur zu gerne unter den Tisch fallen gelassen wird. Was vor 20 Jahren noch kaum jemanden tangierte, soll in unmittelbarer Zukunft unter staatliche Kontrolle gesetzt werden!

Wie wir mittlerweile wissen ist ein großer Kernpunkt der Bitsea die Prüfung auf versteckte Risiken in Software. Der erste Gedanke bei vielen ist die Analyse auf Cybersecurity, oder allgemein auf veraltete oder schlecht gewartete Komponenten, wie wir es bei Log4J erlebt haben. Nun haben wir auch schon gehört, dass durch Bisquat2 auch Entwurfsmusterverletzungen analysiert werden. Kaum einer jedoch wird bei diesem Stichpunkt gleich an Open Source und Lizenzen denken.

Mittlerweile ist die Open-Source-Analyse das wichtigste Standbein der Bitsea. Unsere Kunden werden dabei unterstützt jegliche Bausteine ihrer Software zu dokumentieren. Damit wird eine „Software Bill of Materials“ (SBOM) erstellt. Alle Komponenten werden in der SBOM mit Lizenzen, Copyrights und Schwachstellen aufgelistet, womit die Software auf gegebene Risiken überprüft werden kann. Gemäß des neuen Cyber Resilience Act (CRA) oder des Digital Operational Resilience Act (DORA) sind alle Firmen, die ihre Software gewerblich vertreiben oder, im Falle DORA, mit dem Finanzsektor verbunden sind, dazu verpflichtet, eine Risikobewertung durchzuführen. Grundlage dafür ist die SBOM. Über beide Regulierungen finden Sie hier für DORA und hier für CRA genauere Informationen. Die SBOM ist ein wichtiges Werkzeug um mit Schwierigkeiten und Schwachstellen in Software umzugehen, also diese zu formulieren und mit anderen zu kommunizieren.

Lizenzen sind trickreich. Leute, die zuvor schon im IT-Bereich von kritischer Infrastruktur gearbeitet haben, wissen das. Viele Lizenzen haben bestimmte Bedingungen, wenn ihre Bibliotheken kommerziell benutzt werden. Heißt, der Quellcode mit diesen Lizenzen muss laut Urheber wieder öffentlich zugänglich gemacht werden.

Man kann verstehen, dass viele große Konzerne und vor allem mittelständische Betriebe ihre Software nicht der Allgemeinheit zur Verfügung stellen möchten. Man stelle sich dieses Szenario nur an Hand eines großes Energieversorgers vor…
Zudem möchte man doch beruhigt in seinem elektrisierten Personenkraftwagen nach dem letzten Softwareupdate sitzen mit dem Wissen, dass dessen Software für die nächsten Jahre unangetastetes Firmengeheimnis bleibt – ohne Einwirkungen von außen.

Da nun aber auch namentliche Hersteller auf Open-Source Komponenten in ihrer Software nicht mehr verzichten können, da selber machen teuer und zeitaufwendig ist, werden Firmen wie Bitsea beauftragt, herauszufinden, was sich dort versteckt. Allgemeine Schätzungen gehen davon aus, dass ein durchschnittliches Softwareprodukt circa 80 Prozent Open-Source Code enthält.

Fakt ist, dass das Schaubild des Eisberges mit seiner versteckten Größe unter Wasser wie die Faust aufs Auge passt. Viele Open-source Projekte präsentieren vermeintlich ihre Lizenzen auf Github, wenn man jedoch eine tiefe Lizenzanalyse betreibt, wird schnell klar, dass oft mehr im Busch ist als gedacht. Im Gegensatz zu kommerzieller Software, bei der man genau weiß, was sie beinhaltet, ist Open-Source Software häufig ein schwierig zu überblickendes Sammelsurium. Mit Bisquat2 haben wir vorrangig ein Werkzeug zur Qualitätsanalyse des Source Codes entwickelt. Da Lizenzen uns in unserem Arbeitsalltag aber täglich beschäftigen, wollten wir hierzu Hilfsmittel einbauen, die uns unterstützen können.

Zur Lizenzanalyse stehen uns bereits sehr gute Werkzeuge zur Verfügung wie Flexera SCA, Black Duck, Fossology, Scancode oder ORT. Mit diesen Tools auditieren wir effizient und schnell den Source Code unserer Kunden mit Multifaktoransatz: Jede einzelne Datei wird dabei überprüft und auch problematische Codefragmente werden gegebenenfalls erkannt. Binär- und Mediendateien können ebenfalls analysiert werden. Als Ergebnis erhalten wir eine SBOM, in der Copyrights, Lizenznamen, Lizenztext, diverse Schwachstellen und Sicherheitslücken und andere Parameter der Komponenten aufgezählt werden.

Bisquat2 ist nun fähig diese SBOM einzulesen und bestimmte Sachverhalte der Komponenten nochmals genauer zu überprüfen: Durch die Datenauslese der Berichte können wir durch Bisquat2 nun beispielsweise regelbasiert kontrollieren, ob die Lizenztexte mit Originalvorlagen übereinstimmen. Dies ist eine Funktion, die durchaus wichtig ist: Viele Autoren verändern ihre Lizenztexte, manche schwerwiegend, sodass die Abwandlung sofort ins Auge fällt, manche nur minimal. Hierbei wird es schwierig diese personalisierten Lizenztexte vom Original zu unterscheiden. Liegt eine noch so kleine Änderung vor, muss der Lizenztext entsprechend deklariert werden, um juristischen Konsequenzen vorzubeugen. Da ein Lizenztext oft aus verschiedenen Passagen besteht, ist dieser Abgleich leider nicht einfach umzusetzen: Zusätzlich zu Lizenzpassagen, die unveränderbar sind, gibt es optionale Passagen, die weggelassen werden können, doch wenn sie im Text stehen, wieder genau mit der Vorlage übereinstimmen müssen. Dazu gibt es variable Passagen, in denen ein individuell angepasster Text stehen darf.

Ein weiteres Gimmick ist unsere Ähnlichkeitssuche für Lizenzen in Bisquat2. Sehr viele Lizenzen sehen auf den ersten Blick sehr ähnlich aus. Bei unserer Suche geben wir den Lizenztext ein und bekommen als Ergebnis eine Liste von Lizenzvorschlägen, welche die höchste Übereinstimmung haben. Da wir inzwischen eine sehr große Datenbank für Lizenzen haben, auch mit personalisierten Lizenztexten, können wir die Lizenzen damit schneller zuordnen. Für Außenstehende wirkt diese Funktion vielleicht auf den ersten Blick nicht wichtig, aber sie erleichtert ungemein den Alltag, da ein Werkzeug mit so einer Funktion bisher nicht existierte.

Ein weiterer Schritt ist es, Metadaten aus Repositories heraus zu holen und zu verarbeiten. Dafür benötigen wir Daten, die auf die Sicherheit und Zukunftsfähigkeit eines Projekts schließen lassen. Zum Beispiel geben die Autorenanzahl, die Anzahl der Commits oder Pull-Requests und deren Zeitstempel Aufschluss darüber wie aktiv ein Projekt gewartet, erweitert oder verbessert wird. Sind diese Zahlen niedrig, kann daraus gefolgert werden, dass hier Gefahren für Schwachstellen und Sicherheitslücken entstehen können, wenn Patches nicht mehr regelmäßig zur Verfügung gestellt werden.

Zuletzt muss ich noch auf das Kapitel der Beschaffenheit und der Beziehungen von Lizenzen untereinander eingehen. Es ist wohl das Wichtigste und das Zäheste an der ganzen Lizenzgeschichte. Wie wir schon wissen, sind Lizenzen sehr unterschiedlich. Grob unterteilen wir sie in vier Kategorien, beschreiben, wie sie gehandhabt werden.

Kategorie eins stellt „strong copyleft“ und „weak copyleft“ Lizenzen dar, die Nutzern ihrer Projekte vorschreiben, dass der gesamte (oder Teile) des damit verbundenen Codes wieder veröffentlicht werden muss. Sie verlangen, dass dieser Code wieder der Öffentlichkeit zur Verfügung steht, ohne Kosten oder Bedingungen.

In unsere zweite Kategorie ordnen wir kommerzielle oder unbekannte Lizenzen ein. Hierbei muss erst geprüft werden, ob entweder eine Lizenz erworben werden muss, oder, im Falle des Unbekannten, die darin beschriebenen Klauseln zu dem gewünschten Nutzungsszenario passen.

Die dritte Kategorie bezeichnet „permissive“ Lizenzen. Diese Lizenzen haben nur minimale Restriktionen. Der Code muss nicht wieder frei publiziert werden, meist soll nur das Copyright erhalten bleiben, um dem Autor gerecht zu werden. In Folge kann Software, die mit diesen Open-Source Komponenten arbeitet, geschützt verwendet werden.

Unsere vierte Kategorie behandelt Lizenzalternativen, heißt hier können die Entwickler aus zwei oder mehreren Lizenzen eine passende auswählen, die am besten mit ihrem eigenen Projekt kompatibel ist.

Kompatibilität ist ein weiterer Punkt, der erwähnt werden muss. Nicht alle Lizenzen passen zueinander. Manche Lizenzen schließen die Bedingungen von anderen Lizenzen aus. So verträgt sich zum Beispiel die „copy-left“ Lizenz GPL-2.0-only nicht mit der permissiven Lizenz Apache-1.0. Eine juristische Beratung in dieser Hinsicht bleibt also keinesfalls aus. Dazu spielen dann noch die Abhängigkeiten der lizensierten Komponenten untereinander eine große Rolle, wie man mit eben jenen umgehen kann oder darf.

Je nachdem wie viele Komponenten in einer Software vertreten sind, kann die Übersicht über deren Besonderheiten, heißt Schwachstellen oder Lizenzen, sehr leiden. Mit unserem erstellten Bericht, dessen tabellarische Ansicht für die meisten Personen immer noch schwer zu überblicken ist, generieren wir in Bisquat2 eine 3D-Visualisierung. Mit dieser Visualisierung, die ein FOSS-Graph in 3D darstellt und gleichzeitig die „Free Open Source Software“ (FOSS) aufdröselt, geben wir einen verständlicheren Einblick in diese schwer zu durchdringende juristische Welt. Auf den ersten Blick kann man hier Ketten von Abhängigkeiten erkennen, „schwierige“ Lizenzen der einzelnen Module oder Sicherheitsrisiken.

Wie wir dies genau umgesetzt haben, mit unseren Partnern der H-BRS, werde ich im nächsten Blog schildern. Auch eine weitere Interpretation unseres Praktikanten, die Teil seiner Bachelorarbeit ist, werden wir uns genau ansehen.