In diesem kurzen Artikel gibt zukünftigen oder aktuellen Product Owner das Basiswissen zum Thema Open Source Software Policy an die Hand. Ich zeige dir, warum es wichtig ist, als Product Owner die verwendeten Open Source Komponenten im Blick zu behalten.
Vielleicht ist dein erster Gedanke, dass du als Product Owner mit deinem Produkt gar keine Open Source Software nutzt. Schließlich leitest du ein Entwicklungsteam und ihr entwickelt Individualsoftware, oder? Das ist leider ein Trugschluss. Es ist fast unmöglich, in der modernen Softwareentwicklung ohne Open Source Software auszukommen. Jede genutzte Softwarebibliothek ist eine Open Source Software.
Es ist zwar schwierig, die genaue Anzahl von Open Source Software Komponenten in einem durchschnittlichen Softwareprojekt anzugeben, da es von vielen Faktoren abhängt, wie der Art der Anwendung, der Größe des Projekts, der verwendeten Technologien und der Unternehmensrichtlinien. Ein Projekt kann auch mehrere hundert oder sogar tausende von OSS-Komponenten enthalten, je nachdem wie viele externe Softwarebibliotheken verwendet werden.
Es gibt jedoch Studien, die gezeigt haben, dass ein großer Teil der modernen Software auf Open Source Software aufbaut. Eine solche Studie von WhiteSource, einem Unternehmen, das Lösungen für das Management von Open Source Software anbietet, hat gezeigt, dass in etwa 60-90% aller Codezeilen in Unternehmenssoftware Code von Open Source Software enthalten sind.
Es gibt auch Untersuchungen, die gezeigt haben, dass durchschnittlich etwa 80-90% des Codes in einigen Anwendungen auf OSS aufbauen.
Open Source ist damit überhaupt keine Nische und es ist sehr wahrscheinlich, dass du mit deinem Entwicklungsteam Open Source Software verwendest.
Grundsätzlich ist es so, dass die Open Source Software von jemandem (einem SW-Entwickler) geschrieben sein muss. Mit anderen Worten hat irgendjemand diesen Software Code geschrieben. Diese Person hat damit ein Urheberrecht und kann Nutzern zusätzlich ein Nutzungsrecht geben. Mit diesem Nutzungsrecht können andere Entwickler diese SW nutzen, sie verändern und weiterentwickeln. Dieses Nutzungsrecht wird auch Lizenz genannt und in diesem konkreten Beispiel als Open Source Lizenz. Bekannte Open Source Lizenzen sind MIT, GNU General Public License version 2 oder Common Public License. Es gibt jedoch noch viele weitere Lizenzen.
Es ist Standard, dass der Entwickler dieser Open Source Software eine der bekannten Open Source Lizenzen wählt und keine Individualvereinbarung trifft. Das wäre zwar möglich, allerdings viel zu viel Aufwand.
Im Prinzip werden bei der Lizenzen die folgenden drei Punkte geregelt:
Je nach Anwendungsfall deines Produktes oder auch des jeweiligen Unternehmens, kann es also passieren, dass du bestimmte Open Source Software aufgrund der Lizenz nicht verwenden darfst. Im schlimmsten Fall kommt es zu einer Lizenzverletzung und es droht ein entsprechender Schaden.
Gerade bei größeren Organisationen gibt es vor einer Veröffentlichung eines neuen Produktes einen Check, ob alle Lizenzen der Open Source Komponenten eingehalten sind. Das bedeutet jedoch nicht, dass du dich darauf ausruhen kannst. Sollte sich erst am Ende herausstellen, dass bestimmte Bibliotheken nicht genutzt werden können, kann ein Austausch sehr zeitaufwendig und damit sehr teuer werden.
Neben den Lizenzproblemen gibt es jedoch noch weitere Schwierigkeiten mit der Verwendung von Open Source Software Komponenten. Diese könnten veraltet sein, da der ursprüngliche Entwickler sie nicht aktualisiert oder weiterentwickelt. Noch dazu können eventuelle Schwachstellen innerhalb der verwendeten Bibliotheken auftauchen. Das ist gar nicht so selten und es gab bereits in den letzten Jahren und Monaten prominente Beispiele. Ein letztes Beispiel ist das JSON WebToken Open Source Projekt. Schätzungsweise nutzen über 20.000 Projekte diese Bibliothek zur Erstellung von JWTs.
Um solch eine Schwachstelle schnell schließen zu können, müssen sowohl der Entwickler der Open Source Komponente als auch der Nutzer die Software entsprechend anpassen.
Product Owners sind für die Produktstrategie und den Produkterfolg verantwortlich. Ein wichtiger Bestandteil dieser Verantwortung ist die Überwachung und Nutzung von Open Source Software innerhalb des Produkts. Im schlimmsten Fall kann es dazu kommen, dass ein Produkt nicht compliant ist und vorübergehend eingestellt werden muss.
Zusätzlich können, wie bereits erwähnt, Schwachstellen durch die Verwendung von Open Source Komponenten entstehen. Da die Sicherheit eines Produktes eine nicht funktionale Anforderung ist, musst du diese ebenfalls im Auge behalten.
Um die Projektlaufzeit, den Projekterfolg und das Entwicklerherz nicht zu gefährden, solltest du von Anfang an berücksichtigen, ob es eine Open Source Software Policy im Unternehmen gibt und wie diese zu berücksichtigen sind. Gerade bei großen Unternehmen gibt es eigene Teams, welche sich mit diesem Thema beschäftigen. Diese Herausforderung ist weder neu, noch nicht speziell für bestimmte Unternehmen. Auch eine Dokumentation der verwendeten OSS und deren Lizenzen ist wichtig, um im Falle von Problemen oder Audits schnell handeln zu können.
Neben den Unternehmensanforderungen solltest du dir gemeinsam mit deinem Entwicklungsteam ebenfalls Gedanken machen, wie analysiert werden kann, welche Open Source Komponenten verwendet werden und wie die entsprechende Lizenz dafür ist. Das musst du natürlich nicht manuell machen, sondern gehört meistens schon in einem DevOps-Prozess dazu.
Es gibt sehr viele Tools, welche die Dependencies (verwendete Open Source Komponente, sowie deren Dependencies) aufzeigen. Bitte sprich zuerst mit deinem Entwicklungsteam bzw. wenn vorhanden mit deinem DevOps Engineer. Einige bekannte Tools wie z.B. Gitlab haben bereits Funktionen, um Dependencies zu analysieren und gleich mit bereits bekannten Schwachstellen zu verknüpfen.
Solltest du dich selbst auf die Suche nach anderen Tools machen, wird dir der Begriff SCA (Source Component Analysis) über den Weg laufen. SCA-Tools analysieren den Softwarecode und dokumentieren, welche Bestandteile (also welche Komponenten) enthalten sind. Damit sind genau die Open Source Software Komponenten gemeint. Meistens werden die jeweiligen Komponenten ebenfalls analysiert, ob diese wiederum Open Source Software Komponenten beinhalten.
Der Output ist eine Liste mit verwendeten Bibliotheken, deren Lizenz und eventuelle Schwachstellen.
Solche Tools sollten Teil des DevOps Prozesses sein und somit kontinuierlich durchgeführt werden. Ansonsten erwartet dich und dein Team am Ende eine große Überraschung.
Erzähle uns in einem kostenlosen Erstgespräch mehr über dein individuelles Projekt. Wir helfen dir bei den nächsten Schritten und teilen unser Wissen.
Nachricht schreiben