Während Schwachstellen in Open-Source-Code immer wieder für Schlagzeilen sorgen, wie z. B. Heartbleed und Log4Shell, bleibt eine versteckte Quelle von Open-Source-Risiken unbemerkt – die Nichteinhaltung von Lizenzen. [...]
Open-Source-Softwarelizenzen stellen nach Meinung von Palo Alto Networks eine große Risikoquelle dar, da schon eine einzige nicht konforme Lizenz in der Software zu rechtlichen Schritten, zeitaufwändigen Abhilfemaßnahmen und Verzögerungen bei der Markteinführung eines Produkts führen kann.
Trotz des offensichtlichen Risikos ist die Einhaltung von Lizenzbestimmungen kein leichtes Unterfangen. Die Vielfalt der Open-Source-Lizenzen und die Schwierigkeit, festzustellen, welche Lizenzen für eine Software gelten, machen es schwierig, den Überblick zu behalten, um Lizenzen zu verstehen und zu verwalten.
Palo Alto Networks beleuchtet die Hintergründe dieser oft vernachlässigten Risikoquelle und gibt Tipps zu deren Überwindung:
Wie bei der Suche nach hochgradigen oder kritischen Schwachstellen müssen Unternehmen auch bei der Suche nach nicht konformen Lizenzen das Netz der Open-Source- und transitiven Abhängigkeiten entwirren, das häufig mehr als vier oder fünf Ebenen tief reicht.
Diese Abhängigkeiten führen oft zu mehreren Versionen desselben Open-Source-Pakets, und es ist nicht ungewöhnlich, dass man in diesem Netz versteckt übermäßig restriktive Copyleft-Lizenzen findet.
Um sicherzustellen, dass Lizenzen konform sind, müssen Unternehmen eine fortschrittliche, kontextbezogene Analyse der Softwarezusammensetzung nutzen. Damit gelingt es, die nicht konformen Lizenzen, die das Unternehmen bedrohen, zu identifizieren, erkennen und priorisieren.
Eine Einführung in Open-Source-Lizenzen
Wenn Benutzer den Begriff „Open Source“ hören, gehen sie leicht davon aus, dass sie dieses Paket nach Belieben verwenden können, z. B. indem sie es für die Entwicklung eines kommerziellen Produkts nutzen. Aber auch wenn der Quellcode für die ganze Welt offen ist, ist Open-Source-Code nicht frei von Nutzungsbeschränkungen.
Für Open-Source-Pakete gibt es Lizenzen, die die Verwendung, Wiederverwendung, gemeinsame Nutzung, Änderung und Verteilung des Codes regeln. Hunderte von verschiedenen Open-Source-Lizenzen schreiben vor, wie Benutzer Open-Source-Code verwenden können, und die Strafe für die Nichteinhaltung ist real.
Wenn ein Unternehmen ein Open-Source-Paket nutzt und die Lizenz nicht einhält, könnte es gezwungen sein, seinen proprietären Code als Open Source zu veröffentlichen oder den kostspieligen und zeitaufwändigen Prozess des Entfernens und Ersetzens des nicht konformen Pakets in der gesamten Codebasis zu durchlaufen.
Woher wissen also Verantwortliche, welche spezifischen Anforderungen sie erfüllen müssen, um konform zu bleiben? Hier wird es knifflig, da die Anforderungen je nach Lizenz sehr unterschiedlich sind.
Einige Lizenzen – z. B. Copyleft – sind sehr restriktiv. Andere wiederum sind kostenpflichtig, und wieder andere sind bei korrekter Namensnennung frei verwendbar. Im Allgemeinen lassen sich Open-Source-Lizenzen jedoch in zwei Hauptkategorien einteilen: Copyleft und permissive Lizenzen.
- Copyleft-Lizenzen
Copyleft-Softwarelizenzen sind sehr restriktive Lizenzen, die verlangen, dass Unternehmen jeden Code, der die betreffende Open-Source-Software nutzt, als Open Source zur Verfügung stellen. Diese Lizenzen verlangen, dass sie die Quellcode-Dateien ihrer Software weitergeben, die in der Regel eine Kopie der Lizenzbedingungen enthalten und die Autoren des Codes anerkennen. Die bekannteste Copyleft-Lizenz ist die GNU General Public License (GPL).
- Permissive Lizenzen
Permissive Lizenzen enthalten nur minimale Einschränkungen, wie die Software verwendet, verändert und weitergegeben werden darf. Diese Lizenzen enthalten in der Regel einen Gewährleistungsausschluss. Einige Beispiele für permissive Lizenzen sind die GNU All-permissive License, MIT License, BSD-Lizenzen, Apple Public Source License und Apache License.
Im Jahr 2016 ist die beliebteste Lizenz für freie Software die permissive MIT-Lizenz. Ein bemerkenswertes und erfolgreiches Open-Source-Softwarepaket, das die Apache-Lizenz verwendet, ist Kubernetes.
Eine Fallstudie zur Nichteinhaltung von Copyleft-Lizenzen
Im Jahr 2008 verklagte die Free Software Foundation (FSF) Cisco wegen des Verkaufs von Software der Marke LinkSys, die nicht mit dem verwendeten Open-Source-Code konform war. Wie so oft wurde die nicht konforme Software, die eine GPL-Urheberrechtsverletzung verursachte, im Zuge einer Übernahme in die Software von Cisco integriert.
Angesichts der allgegenwärtigen Open-Source-Software, der Zunahme von Übernahmen und der Tiefe der Abhängigkeitsstrukturen wird es immer schwieriger, Open-Source-Lizenzen zu identifizieren, die tief in den kommerziellen Softwareangeboten verankert sind.
Die Nichteinhaltung kann jedoch die Bemühungen um die Geheimhaltung von kommerziellem geistigem Eigentum zunichtemachen. So kann ein Unternehmen, das eine Lizenz nicht einhält, gezwungen werden, seine Software als Open Source zu veröffentlichen oder den Verkauf dieser Software einzustellen.
Und selbst wenn eine Lizenz nicht so restriktiv ist wie eine Copyleft-Lizenz, kann es sein, dass Teams ihre Software neu entwickeln müssen, um eine wichtige Abhängigkeit zu lösen, was kostspielig ist und die Geschwindigkeit der Veröffentlichung dämpft.
Sich entwickelnde Risiken und kontinuierliche Überwachung der Lizenzkonformität
Als ob es nicht schon kompliziert genug wäre, alle Lizenzen zu identifizieren, kann sich eine Open-Source-Lizenz auch noch jeden Moment ändern. So wurde beispielsweise das weit verbreitete Open-Source-Paket Elasticsearch im Jahr 2021 von einer ehemals permissiven Lizenz auf eine restriktivere umgestellt.
Die Überprüfung der Lizenzkonformität ist keine einmalige Angelegenheit. Stattdessen erfordert das Konformitätsmanagement einen kontinuierlichen Ansatz, der die gleiche Sorgfalt voraussetzt wie andere Open-Source-Sicherheitsprozesse, z. B. die Aktualisierung von Drittanbieterpaketen auf neuere und sicherere Versionen.
Entwicklung einer umfassenden Open-Source-Management-Strategie
Auf den ersten Blick mag die Einhaltung von Open-Source-Lizenzen einfach erscheinen. In Wirklichkeit ist sie jedoch so komplex wie die Natur von Open Source selbst. Und die traurige Wahrheit ist: Selbst, wenn die bestehende Open-Source-Sicherheitsstrategie eine gründliche Überprüfung von Abhängigkeiten und Prozesse zur Verwaltung von Schwachstellen beinhaltet, bleiben möglicherweise immer noch erhebliche Open-Source-Risiken, die Unternehmen nicht angehen.
Nur ein einziges nicht konformes Paket reicht, um eine gesamte Anwendung nicht konform mit den Lizenzanforderungen zu machen. Unternehmen müssen daher eine proaktive und umfassende Open-Source-Sicherheitsstrategie in ihre Strategie integrieren, um ihre Lieferkette angemessen zu schützen.
Durch einen proaktiven Ansatz, der Open-Source-Lizenzprobleme frühzeitig im Entwicklungszyklus identifiziert und behebt, können Unternehmen die Produktivität der Entwickler steigern. Gleichzeitig können sie den Stress verringern, der entsteht, wenn sie später im Entwicklungszyklus nicht konforme Pakete aus ihrer Software herausnehmen und ersetzen müssen.
Die Einführung umfassender Open-Source-Sicherheit kann entmutigend erscheinen, aber sie ist machbar. Wenn man es richtig angeht, kann es sogar entwicklerfreundlich sein. Durch die Integration von Open-Source-Tools wie Checkov in IDEs wie VSCode und PyCharm von Jetbrains können Anwendungsentwickler und DevOps-Teams so früh wie möglich im Entwicklungszyklus Einblicke in Schwachstellen und potenzielle Probleme mit der Lizenzkonformität erhalten.
Auf diese Weise können sie proaktiv Probleme mit nicht konformen Paketen beheben und die Geschwindigkeit ihrer Veröffentlichungen aufrechterhalten.
Be the first to comment