Dieser Beitrag dient als Übersicht über die möglichen Risiken, die Verwendung von Open-Source-Software mit sich bringt.
In der heutigen IT-Welt verbreiten sich Open-Source-basierte Anwendungen immer weiter und spielen mittlerweile eine führende oder wichtige Rolle in Bereichen wie Webserver, Datenbanken, Analytik, Containerisierung und natürlich Softwareentwicklung.
Immer mehr Unternehmen unterschiedlicher Größe entscheiden sich bewusst für den Einsatz von Open-Source-basierten Lösungen. Auch der Gedanke, eine gewisse Souveränität und Unabhängigkeit von wenigen marktbeherrschenden Anbietern zu erlangen, spricht für die Verbreitung von Open-Source-Software.
Hauptarten der Open-Source-Lizenzen
Open-Source-Lizenzen können je nach Anforderungen und Einschränkungen in zwei Hauptkategorien eingeteilt werden: Permissive und Copyleft.
Permissive License
Permissive Lizenzen erlauben es, den Code nach Belieben zu nutzen, zu verändern und weiterzugeben, solange die ursprünglichen Autoren anerkannt werden. Permissive Lizenzen erlauben die Erstellung abgeleiteter Produkte und verlangen als Gegenleistung in der Regel nur die Anerkennung der ursprünglichen Urheber.
Wenn man den Statistiken Glauben schenken darf, wird die Mehrheit der verwendeten Lizenzen den permissiven Lizenzen zugeordnet: Most popular open source licenses worldwide in 2021 In der Vergangenheit war es umgekehrt.
Die bekanntesten Permissive Lizenzen sind:
- Apache License 2.0
- MIT (Massachusetts Institute of Technology) License
- BSD (Berkeley Software Distribution) License
z.B. der Cloud Native Computing Foundation (CNCF) wird empfohlen, Projekte mit Apache 2.0 zu lizenzieren.
Copyleft License
Copyleft-Lizenzen (werden auch "viral" bezeichnet) sind ein wenig strenger, obwohl das grundlegende Prinzip ähnlich bleibt. Die Copyleft-Lizenz erlaubt weiterhin, den Code zu verwenden, zu ändern und zu verteilen. Aber wenn Sie den Code verteilen, müssen die Änderungen (Quellcode) unter derselben Lizenz ebenfalls offenlegen.
Die Veröffentlichungsregel gilt nur, wenn der modifizierten Code außerhalb der eigenen Organisation verteilt wird. Bei interner Verwendung müssen die Änderungen (in der Regel, typische Ausnahme: AGPL) nicht veröffentlicht werden.
Die beliebteste Vertreter der Copyleft-Lizenzen sind:
- GNU General Public License (GPL) 3.0
- GNU General Public License (GPL) 2.0
- GNU Lesser General Public License 2.1
Open-Source-Lizenzen: Compliance und andere Risiken
Die Wahl zwischen einer „Open Source“- und einer „Closed Source“-Lösung ist weit mehr als die Wahl zwischen "kostenpflichtig" und "kostenlos", zwischen "ohne Support" und "mit Support".
Die richtige Entscheidung ist sehr individuell und muss für jede Organisation einzeln bewertet werden, da eine Reihe wichtiger Aspekte berücksichtigt werden müssen.
Kosten
Obwohl das Thema Kosten und die damit verbundenen Risiken seit langem bekannt sind, ist es angebracht, einige Worte darüber zu verlieren.
Auch wenn keine Lizenzkosten anfallen, ist die Implementierung in einer Organisation nicht kostenlos. Je nach Komplexität der Lösung und Verfügbarkeit der entsprechenden Spezialisten, können die Implementierungskosten sehr hoch sein.
Der routinemäßige Support und die Konfiguration vieler Open-Source-Anwendungen sowie deren Anpassung an die tatsächlichen Bedürfnisse erfordern oft sehr spezifische und tiefgreifende Erfahrungen. Ist diese Erfahrung nicht vorhanden, muss sie eingekauft werden. Dies kann entweder durch die Einstellung interner Spezialisten oder durch Outsourcing geschehen.
Compliance-Risiken
Vermeintliche Code-Sicherheit
Es gibt sicherlich eine berechtigte Meinung, dass Open Source sicher ist. Dies wird mit der Möglichkeit begründet, den Quellcode überprüfen zu dürfen, insbesondere im Vergleich zur proprietären „Black Box“.
Ist das wirklich so? Vor allem dann, wenn die Anwendung aus Tausenden und Abertausenden von Codezeilen besteht und mehrere „Dependencies“ hat und auch mehrere externe Open-Source-Bibliotheken verwendet. Und diese „Dependencies“ haben auch ihre eigenen „Dependencies“ und auch ihre eigenen externen Bibliotheken... Log4j ist das bekannteste Beispiel dafür.
Lizenz-Compliance-Risiken
Das Thema „Lizenz-Compliance“ ist oft viel problematischer, als es auf den ersten Blick scheint. Wie wir bereits wissen, sind Open-Source-Lizenzen recht spezifisch und wenn keine Zahlung geleistet wurde, bedeutet das nicht, dass es keinen Rechteinhaber gibt.
Potentielle Lizenzierungsrisiken konnten in drei Bereiche unterteilt werden:
Vermischung von verschiedenen Lizenzen
Nehmen wir als Beispiel einen Kubernetes Cluster und die darauf laufenden Workloads.
Einige Komponenten sind permissiv lizenziert und haben wenige Einschränkungen, z.B. „Apache License 2.0“. Andere Komponenten können eine restriktivere „GNU General Public License“ (Copyleft) enthalten und den Nutzer quasi dazu zwingen, modifizierte Versionen als Quellcode freizugeben. Wenn ich die Rechtslage richtig verstehe, muss sogar der gesamte Quellcode unter der Copyleft-Lizenz veröffentlicht werden, auch wenn er mit Code vermischt wurde, der unter einer permissiven Lizenz steht.
Kompatibilität der Lizenzen
Die Frage der Kompatibilität überschneiden sich in gewisser Weise mit dem oben Punkt. Open Source Lizenzen haben unterschiedliche Nutzungsbedingungen. Daher ist es rechtlich nicht zulässig, Code unter einer bestimmten Lizenz mit Code unter einer anderen Lizenz zu kombinieren.
Selbst Lizenzen, die der gleichen Kategorie zugeordnet sind, sind nicht miteinander kompatibel. z.B. beide Copyleft-Lizenzen: GNU General Public License (GPL) und Eclipse Public License (EPL).
Manchmal sind die Lizenzbedingungen wirklich kurios. Dieser Satz "The software shall be used for good, not evil" stammt von Douglas Crockford, dem Urheber der JSON-Datenstruktur. Wie man diese Klausel richtig interpretiert, ist mir ein Rätsel.
Änderung der Lizenzbedingungen
Die Lizenzbedingungen von Open-Source-Projekten können sich im Laufe der Zeit aus dem einen oder anderen Grund ändern. Theoretisch ist es möglich, dass die Permissive License in eine Copyleft License umgewandelt wird. Eine neue Version kann auch die Bedingungen anpassen, die man erfüllen muss, aber nicht erfüllen kann oder will.
Vertrauen ist gut, Kontrolle ist besser!
Wie man sieht, kann der unkontrollierte Einsatz von Open-Source-Lösungen sowohl aus sicherheitstechnischer als auch aus rechtlicher Sicht zu bösen Überraschungen führen.
Es reicht nicht mehr aus, in der CI/CD-Pipeline nur nach Schwachstellen und bösartigen Funktionen/Komponenten in den verwendeten Open-Source-Paketen zu suchen. Es werden auch Werkzeuge benötigt, die Open-Source-Komponenten identifizieren und die entsprechenden Lizenzen überprüfen, um sicherzustellen, dass das Projekt alle Lizenzbedingungen einhält.
Die Tools zur Bewältigung der oben genannten Herausforderungen werden im weiteren Beitrag erläutern.