Open-Source sicher einsetzen

Open-Source-Software sicher in Produkten einzusetzen bedeutet, vier Anforderungen zu erfüllen: eine vollständige Software-Stückliste (S-BOM) erstellen, die tatsächlich enthaltenen Lizenzen prüfen, Lizenzverpflichtungen bei der Auslieferung einhalten und bekannte Sicherheitslücken in verbauten Komponenten kontinuierlich überwachen.

Das Wichtigste in Kürze

• Wer Software an Dritte weitergibt, ist als Distributor an die Lizenzbedingungen der verbauten Open-Source-Komponenten gebunden, unabhängig davon, ob die Software kostenfrei von GitHub bezogen wurde.
• Eine Software-Stückliste (S-BOM) ist in vielen Lieferketten bereits Kaufvoraussetzung und wird durch den Cyber Resilience Act der EU zur regulatorischen Pflicht für Softwarehersteller.
• Hinter jeder direkten Abhängigkeit im Build-System steckt ein Eisberg: Für ein eigenes Modul kommen auf zehn direkte Dependencies oft hundert weitere transitive Abhängigkeiten.
• Die Lizenz-Metadaten in Paketmanagern stimmen häufig nicht mit dem tatsächlichen Lizenztext überein, was bedeutet, dass die Beschriftung eines Pakets keine verlässliche Rechtsgrundlage ist.
• Für abgekündigte Software ohne aktiven Wartungsvertrag verlangt der Cyber Resilience Act dennoch, dass Hersteller Sicherheitslücken melden und gegebenenfalls beheben.

Open Source ist nicht gleich frei verfügbar

Code auf GitHub ist nicht automatisch Open Source. Erst eine Open-Source-Lizenz macht aus programmiertem Code Open-Source-Software. Steht keine Lizenz dabei, handelt es sich um privates Eigentum, das du ohne Einverständnis des Rechteinhabers nicht nutzen darfst.

Dirk Riehle, Professor für Open Source Software an der Uni Erlangen, vergleicht das mit einem Apfelbaum im Nachbargarten: Nur weil du den Apfel sehen und nach ihm greifen kannst, gehört er dir nicht. Auf GitHub liegen auch proprietär lizenzierte Projekte. In jedem Fall musst du nachlesen, was der Eigentümer erlaubt.

Der Befund ist trotzdem eindeutig: Open-Source-Software ist meist gute Software, und sie steckt fast überall. 80 bis 95 Prozent heutiger Software in einem Produkt ist Open-Source-Software. Die Verbreitung ist also kein Randthema, sondern der Normalfall in der Entwicklung.

Reine Nutzung ist harmlos, Weitergabe nicht

Wer Open-Source-Software nur selbst nutzt, hat in der Regel keine Pflichten. Das ist die wichtigste Entwarnung für alle, die ein Tool herunterladen und im eigenen Haus einsetzen. Die Rechtezusprechung bei Open Source erlaubt dir, die Software kostenfrei zu nutzen und zu modifizieren.

Die Pflichten entstehen erst, sobald du Software an Dritte weitergibst. In dem Moment wirst du zum Distributor, und damit greifen die Lizenzbedingungen in vollem Umfang. Ein Webserver, der JavaScript-Code an den Browser ausliefert, ist bereits eine solche Weitergabe.

Diese Grenze zwischen Endnutzer und Distributor entscheidet darüber, ob du Lizenztexte genau lesen musst oder nicht. Für Softwarehersteller liegt der Fall klar: Sie sind fast immer Distributoren.

Permissive Lizenzen verlangen Nennung, Copyleft verlangt mehr

Open-Source-Lizenzen zerfallen in zwei Gruppen: solche mit Copyleft-Klausel und solche ohne. Diese Unterscheidung bestimmt, wie aufwendig die Nutzung im eigenen Produkt wird.

Permissive Lizenzen wie die MIT-Lizenz verlangen vor allem Attribuierung. Du musst sauber deklarieren, wessen Code du verbaust, also die Copyright-Vermerke und Lizenztexte weitergeben. Deinen eigenen Quelltext musst du nicht offenlegen, auch wenn du die Komponente modifiziert hast.

Copyleft-Lizenzen aus der GPL-Familie verlangen das Gegenteil. Verbaust du Copyleft-lizenzierten Code und gibst dein Produkt weiter, musst du den Empfängern auch deine eigenen Modifikationen unter derselben Lizenz bereitstellen. Die einlaufende Lizenz muss die auslaufende Lizenz sein.

Riehle hält sich bei der moralischen Frage zurück, ob das Offenlegen verpflichtend sein sollte. Sein Argument ist pragmatisch: Die Lizenz drückt aus, was der ursprüngliche Entwickler will.

Es gibt viele Entwickler, die sagen, ich will meine Nutzer nicht zwingen, ihren Quelltext offenzulegen, dann nehmen sie eine permissive Lizenz. Und es gibt viele, die sagen, ich will jene, die meinen Quelltext nutzen, zwingen, ihren eigenen Quelltext offenzulegen, dann nutzen sie eine Copyleft-Lizenz.

Dirk Riehle

Community Open Source und kommerzielles Open Source folgen verschiedenen Logiken

Hinter Open-Source-Projekten stehen zwei grundverschiedene Motivationen. Wer verstehen will, warum ein Projekt existiert und wie verlässlich es gepflegt wird, sollte diese Trennung kennen.

Community Open Source entsteht gemeinschaftlich. Heute sind das meist bezahlte Angestellte, die im Auftrag ihrer Arbeitgeber an Komponenten arbeiten, die alle Beteiligten brauchen, aber die nicht wettbewerbsdifferenzierend sind. Kein Unternehmen hat einen Vorteil davon, diese Arbeit allein zu stemmen, also teilt man die Kosten auf mehrere Schultern.

Kommerzielles Open Source verfolgt ein Geschäftsziel. Riehle unterscheidet hier Distributoren wie SUSE, Univention und Red Hat von Single-Vendor-Firmen, die eine Software selbst entwickeln und unter einer Open-Source-Lizenz bereitstellen.

Das klassische Beispiel ist MySQL, aus dem später MariaDB wurde. Der Hersteller stellte die Datenbank kostenfrei als Open Source bereit und verkaufte parallel eine kommerzielle Lizenz. Als Rechteinhaber kann ein Unternehmen beliebig oft lizenzieren: Die Open-Source-Lizenz ist eine, die kommerzielle eine zweite.

Beim Open-Core-Modell sind Teile kostenfrei, einzelne Funktionen kostenpflichtig. Bei MySQL betraf das ein Clustering-Feature, das nur professionelle High-End-Anwender brauchten. Für eine private Website reicht die Open-Source-Version. Heute verschiebt sich die Grenze oft auf den Betrieb: Self-Hosting ist frei, der gehostete Web-Service ist die kommerzielle Leistung.

Was eine Software-Stückliste ist und warum Kunden sie verlangen

Die Software-Stückliste, englisch Software Bill of Materials oder S-BOM, listet alle Komponenten auf, die in einem Produkt verbaut sind. Sie ist die zentrale Datenstruktur, um Open Source sicher einzusetzen.

Im Build-File sieht ein Entwickler nur die First-Level-Dependencies, also die Bibliotheken, gegen deren Schnittstellen er programmiert. Darunter liegt ein Eisberg. Diese direkten Abhängigkeiten haben eigene Abhängigkeiten, und so entsteht ein tiefer Dependency-Graph.

Die Proportionen sind ernüchternd: Für ein einziges eigenes Modul können zehn direkte Dependencies und hundert weitere darunter zusammenkommen. Ein gutes Build-System löst diesen Graphen über Package-Manager auf, sonst ließe sich gar kein Binary erzeugen. Klopft man den Graphen flach, ergibt sich die Stückliste.

Diese Stückliste ist heute eine Kaufanforderung. Kunden wollen wissen, was in der Software steckt, bevor sie sie überhaupt abnehmen. In den USA war die Auslieferung einer S-BOM per Executive Order verpflichtend, wenn man an US-Ministerien verkauft. In der EU treibt der Cyber Resilience Act in eine ähnliche Richtung.

Sicherheitslücken sind dein Problem, auch wenn ein Hersteller dahintersteht

Wer Software betreibt, muss selbst überwachen, was darin verbaut ist. Die Stückliste reicht erst, wenn du sie laufend gegen neu bekannt gewordene Sicherheitslücken abgleichst.

Riehle macht das am Beispiel einer Bank deutlich. Betreibt sie ein Produkt mit einer verwundbaren Open-Source-Komponente wie bei Log4Shell, und jemand nutzt die Lücke aus, dann sind es ihre Kundendaten, die auf dem Schwarzmarkt landen. Auf den Hersteller zu zeigen hilft dann nicht.

Das Beheben des Problems geht zwar an den Hersteller zurück. Doch im Ernstfall musst du die Software schlimmstenfalls abschalten, wenn sie ein offenes Einfallstor bietet. Deshalb muss jeder Endanwender monitoren, nicht nur produzieren.

Wie die Fehlerbehebung durch die Lieferkette fließt

Software-Lieferketten funktionieren wie physische: Software wird in Software verbaut, die wieder in Software verbaut wird. Bei einem Sicherheitsproblem arbeitet sich die Verantwortung durch diese Kette zurück.

Eine Besonderheit dreht die Richtung um. Sicherheitslücken in Open-Source-Komponenten werden idealerweise erst öffentlich gemacht, wenn der Bugfix schon existiert. Die korrigierte Komponente steht am Anfang der Kette also bereit, bevor das Problem bekannt wird.

Von dort muss der Fix nach vorn fließen. Jeder Nutzer muss ein Update durchführen und die Komponente von Upstream holen. Das wird schnell schwierig, denn die korrigierte Komponente ist womöglich nicht mehr kompatibel mit anderen Dependencies. Über mehrere Schritte bis ins kommerzielle Endprodukt kann das dauern.

Verschärft wird das durch abgekündigte Software. Viele Unternehmen betreiben Software ohne Wartungsvertrag. Der Cyber Resilience Act legt nahe, dass man auch dafür zuständig bleibt: mindestens informieren, gegebenenfalls reparieren, selbst wenn keine Lizenzverträge mehr vorliegen. Vieles daran ist regulatorisch noch nicht geklärt.

Werkzeuge helfen, aber die Arbeit bleibt händisch

Software Composition Analysis, kurz SCA, ist die Werkzeugkategorie, die analysiert, was in einem Produkt verbaut wurde. Solche Tools bestimmen die Stückliste und überwachen sie anschließend.

Riehle nennt das eigene SCA-Tool, erreichbar unter scar-tool.com, sowie kommerzielle Anbieter wie Black Duck, Fossa und Fossa ID. Ursprünglich dienten diese Werkzeuge der Lizenzprüfung, zunehmend auch der Sicherheit. Der Markt ist in Bewegung, weil die regulatorischen Anforderungen aus EU und BSI wachsen.

Eine einfache Lösung gibt es trotzdem nicht. Keine Software schaut ins Rechenzentrum und erstellt automatisch eine vollständige Stückliste, schon gar nicht auf Binärebene. Du brauchst zuerst ein Inventar deiner betriebenen Software, oft von Hand erstellt, und musst dann pro Software die Stückliste eruieren.

Die ehrliche Lage: Die meisten Unternehmen haben noch niemanden, der für Open Source zuständig ist.

Warum die Metadaten das eigentliche Problem sind

Die Beschriftung einer Komponente stimmt nicht zwangsläufig mit ihrem Inhalt überein. Genau hier liegt der größte Aufräumbedarf, und KI löst das nicht.

Ein Package-Manager kann eine Komponente als MIT-lizenziert ausweisen, obwohl mittendrin GPL-lizenzierter, also Copyleft-lizenzierter Code steckt. Das passiert leicht. Die Metadaten zu Lizenzen sind ausgesprochen schlecht.

Dazu kommt das Sicherheitsproblem unterhalb der Komponentenebene. Wenn jemand einen Algorithmus mit bekanntem Bug aus einer Quelle wie Stack Overflow in eine Bibliothek kopiert hat, steckt der Fehler mitten im Code und wird als solcher nicht mehr erkannt. Wo solche bekannten Bugs sitzen, lässt sich kaum bestimmen, bis sie für die konkrete Komponente öffentlich werden.

Die Industrie versucht, diese Probleme an der Quelle zu beheben. Bisher hat jeder Hersteller dieselben Open-Source-Komponenten redundant geprüft und ihre Lizenzen analysiert, oft hundert- oder tausendfach parallel. Sinnvoller wäre, das einmal im Open-Source-Projekt selbst zu tun.

Initiativen der Linux Foundation und der Eclipse Foundation arbeiten daran, diese Bestandsaufnahme in die Projekte zurückzutragen. Der Weg ist eingeschlagen, aber er wird viele Jahre dauern.

Vier Anforderungen, die Open Source an jeden Hersteller stellt

Wer Open Source professionell einsetzt, muss vier Dinge im Griff haben. Riehle fasst sie als Kern guter Open Source Governance zusammen.

Beim letzten Punkt sieht Riehle eine konkrete Gefahr. Eine Website, die JavaScript-Code ausliefert, stellt eine Distribution dar und braucht dafür Rechtsvermerke. Das macht praktisch niemand. Er erwartet darum irgendwann eine markante Abmahnwelle.

Häufig gestellte Fragen

Darf ich Code von GitHub verwenden, wenn keine Lizenz dabeisteht?

Nein. Erst eine Open-Source-Lizenz macht aus veröffentlichtem Code Open-Source-Software. Fehlt sie, handelt es sich um privates Eigentum, das ohne Einverständnis des Rechteinhabers nicht genutzt werden darf. Auf GitHub liegen auch proprietär lizenzierte Projekte. Dirk Riehle vergleicht das mit einem Apfel im Nachbargarten: Sichtbar und greifbar heißt nicht, dass er dir gehört.

Entstehen Lizenzpflichten auch, wenn Open Source nur intern eingesetzt wird?

In der Regel nicht. Wer Open-Source-Software ausschließlich selbst nutzt und modifiziert, hat üblicherweise keine Pflichten. Die Verpflichtungen greifen erst bei der Weitergabe an Dritte, denn damit wird man zum Distributor. Diese Grenze wird schneller überschritten als gedacht: Schon ein Webserver, der JavaScript-Code an den Browser ausliefert, ist eine Weitergabe.

Muss ich meinen eigenen Quelltext offenlegen, wenn ich eine MIT-lizenzierte Bibliothek verändere?

Nein. Permissive Lizenzen wie MIT verlangen vor allem Attribuierung, also die Weitergabe der Copyright-Vermerke und Lizenztexte. Der eigene Quelltext bleibt geschlossen, auch bei Modifikationen an der Komponente. Anders bei Copyleft-Lizenzen aus der GPL-Familie: Wer solchen Code verbaut und das Produkt weitergibt, muss die eigenen Modifikationen unter derselben Lizenz bereitstellen.

Wie verdienen Unternehmen Geld mit Software, die sie unter einer Open-Source-Lizenz veröffentlichen?

Als Rechteinhaber kann ein Unternehmen dieselbe Software beliebig oft lizenzieren: die Open-Source-Lizenz als eine, eine kommerzielle als zweite. MySQL, aus dem später MariaDB hervorging, ist das klassische Beispiel. Beim Open-Core-Modell sind einzelne Funktionen kostenpflichtig, bei MySQL etwa ein Clustering-Feature für High-End-Anwender. Oft liegt die Grenze heute beim Betrieb: Self-Hosting frei, gehosteter Service kommerziell.

Wie viele Fremdkomponenten stecken tatsächlich in einem Softwareprodukt?

Deutlich mehr, als im Build-File sichtbar ist. Dort sieht ein Entwickler nur die First-Level-Dependencies, gegen deren Schnittstellen er programmiert. Darunter liegt ein tiefer Dependency-Graph: Für ein einziges eigenes Modul kommen auf zehn direkte Abhängigkeiten oft hundert weitere. Insgesamt bestehen Produkte zu 80 bis 95 Prozent aus Open-Source-Software.

Wer trägt die Verantwortung, wenn eine Sicherheitslücke in einer verbauten Open-Source-Komponente ausgenutzt wird?

Der Betreiber trägt die Folgen, auch wenn ein Hersteller dahintersteht. Betreibt eine Bank ein Produkt mit einer verwundbaren Komponente wie bei Log4Shell, landen ihre Kundendaten auf dem Schwarzmarkt, und der Verweis auf den Lieferanten hilft nicht. Die Behebung geht zwar an den Hersteller zurück, im Ernstfall muss man die Software aber abschalten. Deshalb muss jeder Endanwender selbst überwachen.

Kann man sich auf die Lizenzangaben in Paketmanagern verlassen?

Nein. Die Beschriftung eines Pakets stimmt häufig nicht mit dem tatsächlichen Inhalt überein: Eine Komponente kann als MIT-lizenziert ausgewiesen sein, obwohl mittendrin GPL-lizenzierter Code steckt. Die Lizenz-Metadaten gelten als ausgesprochen schlecht. Deshalb gehört zur Prüfung, in die Pakete hineinzuschauen, statt der Deklaration zu vertrauen.

Erstellen Werkzeuge zur Software Composition Analysis die Stückliste vollautomatisch?

Nein. Keine Software schaut ins Rechenzentrum und erzeugt daraus eine vollständige Stückliste, auf Binärebene erst recht nicht. Zuerst braucht es ein Inventar der betriebenen Software, das oft von Hand entsteht, danach wird pro Software die Stückliste eruiert. SCA-Werkzeuge bestimmen und überwachen sie anschließend, dienten ursprünglich der Lizenzprüfung und decken zunehmend auch Sicherheit ab.