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.