Den Quellcode von Open-Source-Software (OSS) kann bekanntlich jeder einsehen, verändern und weitergeben. Meistens entwickeln mehrere Programmierer diese Software gemeinsam und teilen ihre Arbeit mit anderen. Anders als proprietäre Software ist OSS oft kostenlos, was zu einem größeren Nutzerkreis führt. Benutzer können die Software aufgrund des frei zugänglichen Quellcodes ändern und an ihre Bedürfnisse anpassen. Zudem führt der gemeinschaftliche Entwicklungsprozess zu schnellen und häufigen Aktualisierungen, was zu einer stabilen und sicheren Software führen sollte.

Dank dieser Vorteile wird OSS heute in vielen Anwendungen eingesetzt - von Betriebssystemen über Webserver bis hin zu mobilen Anwendungen. Dabei entstehen Risiken, wenn die Nutzung nicht gut gemanagt wird. Unternehmen können dann leicht unbeabsichtigt gegen Lizenzregeln verstoßen, was zu rechtlichen und finanziellen Konsequenzen führen kann.

Eine SBoM hilft, FOSS-Artefakte gut zu managen

Deshalb ist es wichtig, Transparenz über die Verwendung von OSS in den eigenen Produkten zu haben. Eine vollständige Inventarliste, die sogenannte Software Bill of Materials (SBOM), hilft dabei, sofern sie gepflegt und stets aktuell gehalten wird. Die SBOM enthält Informationen darüber, welche quelloffene Software in welcher Version wo verwendet wird und wie die Lizenzbedingungen aussehen (siehe auch: Was ist eine SBOM?).

SBOMs manuell zu erstellen und zu pflegen, ist nicht praktikabel. Das liegt an der großen Anzahl der verwendeten FOSS-Komponenten und des Open-Source-Codes, der von Frameworks oder Entwicklern durch direktes Kopieren von Fragmenten in die Quelldateien meist unbemerkt eingeführt wird. Deshalb hat es sich bewährt, die gesamte Codebasis mit einem Tool zu scannen, das Open-Source-Bibliotheken und -Snippets aufspürt. Die Erstellung der SBOM erfordert dann eine manuelle Identifizierung der FOSS-Artefakte auf der Grundlage der Scan-Ergebnisse.

FOSS-Risiken wie Lizenz- und Copyleft-Probleme begrenzen

Eine solche Analyse muss vor der Veröffentlichung eines Softwareprodukts vorgenommen werden, um sicherzustellen, dass alle Lizenzen bekannt sind und die Verpflichtungen erfüllt wurden. In den meisten Fällen deckt die Untersuchung Lizenzkonflikte und Copyleft-Probleme auf, die eine Freigabe des fertigen Produkts als Open Source erfordern würden. Diese Schwierigkeiten müssen beseitigt werden.

Um Verzögerungen kurz vor der Produkteinführung zu vermeiden, sollte die Analyse in regelmäßigen Abständen während des Entwicklungsprozesses vorgenommen werden. Sobald die SBOM verfügbar ist, gilt es, die Kompatibilität der jeweiligen Lizenzen und der zugehörigen Verpflichtungen technisch und rechtlich zu bewerten. Unterschiedliche Nutzungsarten erfordern eine Einzelfallanalyse.

Darüber hinaus können für einen regelkonformen Einsatz der Open-Source-Artefakte bestimmte Nutzungsarten nur für bestimmte Komponenten erlaubt sein, während andere ausgeschlossen werden müssen. Um das zu durchblicken, ist es notwendig, dass rechtliches und technisches Wissen miteinander verknüpft werden. Es sollten also Softwareentwickler genauso wie die Rechtsabteilung eingebunden sein.

Policy sollte Open-Source-Nutzung regeln

Neben der Pflege einer SBOM sind weitere Elemente des FOSS-Managements erforderlich. So gilt es, eine Policy festzulegen, die die Rahmenbedingungen für die Nutzung von Open Source definiert. Unterstützende Prozesse und Richtlinien müssen definiert und eingehalten werden. Auch gilt es, Entwickler und andere Beteiligte angemessen zu schulen und sich der Risiken bewusst zu werden, die mit der Verwendung von Open-Source-Software verbunden sind.

Da das FOSS-Management sowohl Zeit als auch Spezialwissen erfordert, gibt es inzwischen zahlreiche Unternehmen und Organisationen, die diese Aufgaben - gerade während der Release-Perioden - an einen spezialisierten Dienstleister auslagern. Diese Unternehmen ziehen es vor, dass ihre Mitarbeiter sich im Entwicklungsprozess auf Innovation und Wertschöpfung konzentrieren, nicht auf komplexe Verwaltungsthemen.

Betriebe können ihre Lizenz- und Entwicklungskosten für Infrastruktur und Softwareentwicklung mit dem Einsatz von FOSS also deutlich senken, aber sie gehen mit den Lizenzverpflichtungen sowie mit potenziellen Sicherheits- und Compliance-Probleme auch neue Risiken ein, die teuer werden können. Deshalb braucht es standardisierte OSS-Richtlinien und -Praktiken.

Wir empfehlen folgendes Vorgehen:

• Scannen Sie die Codebasis Ihres neuen Softwareprodukts und alle vorgelagerten Quellcode-Artefakte mit einem effektiven Tool. Erstellen Sie auf dieser Basis eine Liste der eingesetzten FOSS-Komponenten.

• Identifizieren Sie Lizenzbedingungen und mögliche Problemherde in einem Bericht und planen Sie die Prozesse, mit denen Sie ein konformes Produkt erstellen können.

• Open-Source-Lizenzen verlangen, dass Anforderungen wie etwa die Weitergabe des Lizenztextes oder Copyleft-Verpflichtungen erfüllt werden. Mit einer technischen Analyse können Sie klären, wie das gelingen kann.

• Alle aus Open-Source-Komponenten extrahierten Lizenztexte und Copyright-Hinweise müssen in die Lizenzdokumentation auf Dateiebene aufgenommen werden. Diese Dokumentation muss zusätzlich zum kommerziellen Produkt bereitgestellt werden.

FOSS-Komponenten inventarisieren

Die eingesetzten FOSS-Komponenten zu inventarisieren, ist auch für das Management von Schwachstellen hilfreich. Viele Unternehmen waren beispielsweise von erheblichen Sicherheitslücken in FOSS-Komponenten betroffen, als das Log4j-Problem in neueren Versionen einer weit verbreiteten Java-Bibliothek auftrat. Zwar gab es schnell einen Fix, aber nur diejenigen, die wussten, welche Version von Log4j an welcher Stelle verwendet wurde, konnten ihre Daten zeitnah vor Risiken schützen (siehe auch: Log4j - ist Open Source das Problem?)

Das Verwalten von OSS ist vor allem für Unternehmen schwierig, deren Kerngeschäft nicht die Softwareentwicklung ist. Beispielsweise stellen Open-Source-Lizenzen oft bestimmte Anforderungen wie etwa die Namensnennung oder die Weitergabe von Änderungen an die Gemeinschaft. Nur wer sie befolgt, kann die Software legal nutzen. Die Nichteinhaltung kann rechtliche und finanzielle Konsequenzen nach sich ziehen, zum Beispiel in Form von Gerichtsverfahren oder Geldstrafen.

Unternehmen sollten also die Bedingungen jeder Lizenz kennen und Prozesse implementieren, damit die jeweiligen Bestimmungen während des Softwareentwicklungs-Zyklus auch sicher eingehalten werden. Wer das berücksichtigt, kann die Vorteile von OSS nutzen und die Risiken in den Griff bekommen. (hv)