Open Source Software: Frage der Sicherheit und Compliance Und wer prüft genau?

Open Source Software (OSS) ist zwar kostenfrei, aber nicht frei von Verpflichtungen. Diese reichen von der Veröffentlichung einer Urheberrechtserklärung oder des Lizenztextes bis hin zur Bereitstellung des gesamten Quellcodes des Softwareprodukts. Das ist vielen Unternehmen jedoch nicht immer klar. Zudem ist den Verantwortlichen in der Regel nur ein kleiner Prozentsatz der genutzten Open Source Komponenten in ihren Produkten überhaupt bekannt. Das kann gefährliche Folgen haben. Wer nicht genau nachverfolgt, welche Komponenten in welchen Produkten zum Einsatz kommen, kann unmöglich die Compliance der jeweiligen Lizenzvorgaben einhalten. Ganz zu schweigen von der Anwendung und Bereitstellung der neuesten Updates und Patches, um bekannte Schwachstellen zu beheben und Sicherheitslücken zu schließen.

Wissen was läuft

Unternehmen können sich mit fünf Schritten eine Übersicht bei der Verwendung von Open Source-Komponenten verschaffen und so den Grundstein legen, um Sicherheits– wie Compliance-Risiken langfristig zu minimieren.

Schritt 1: Den Weg von Open Source ins Unternehmen nachvollziehen. Wie kommt Open Source überhaupt in die Softwareprodukte? Der klassische Weg ist über einen Programmierer, der bei der Entwicklung eine Open Source-Komponente verwendet, den Quellcode herunterlädt und in das Softwareprodukt integriert.

Dabei ist es heute üblich einen sogenannten Repository-Manager zu nutzen, um die gewünschten Komponenten zu finden. Repository-Manager wie Maven, Nuget oder npm stellen den Quellcode oder die kompilierte Binärdatei zum Download zur Verfügung und berücksichtigen dabei alle mit der Komponente verbundenen Abhängigkeiten. Die Open-Source-Komponenten werden in einem separaten Repository außerhalb des klassischen Quellcode-Managementsystems gespeichert.

Zudem gibt es auch Teilkomponenten, die zu einer kommerziellen oder größeren Open-Source-Komponente gehören. Eine einzelne, übergeordnete Komponente kann durchaus mehrere Open-Source-Teilkomponenten oder entsprechende Abhängigkeiten umfassen, die jedoch häufig nicht offengelegt oder verwaltet werden. Darüber hinaus wird Open Source auch in Form von Runtime-Infrastrukturmodulen eingesetzt wie Webserver, Betriebssysteme oder Datenbanken und ist daher nicht auf den ersten Blick offensichtlich. Open Source ist jedoch nicht allein Sache der Entwickler. Die genannten Komponenten sind grundsätzlich für jeden zugänglich – für Grafikdesigner, Einkäufer, professionelle Dienstleister, IT-Administratoren und viele andere Mitarbeiter im Unternehmen.

Schritt 2: Gezielte Suche nach Open Source Software: Sind die Prozesse klar, wie Open Source ins Unternehmen gelangt, kann als nächster Schritt ermittelt werden, welche dieser Komponenten wie genutzt und weitergegeben werden, und welche Geschäftsprozesse von ihnen abhängen. Ähnlich wie in der Fertigung lässt sich auch für Software eine Stückliste (BOM) erstellen, die detailliert festhält, welche Open Source Software in welchen Produkten genutzt wird. Die Stückliste hilft lizenzrechtliche Verpflichtungen einzuhalten, OSS-Richtlinien anzupassen und auf bekannte Schwachstellen umgehend zu reagieren.

Bei der Suche nach OSS werden nicht selten Open-Source-Pakete mit lizenzrechtlichen Verpflichtungen gefunden, die für Unternehmen unmöglich einzuhalten sind. Ein Verstoß gegen Lizenzbestimmungen folgt automatisch, so dass oft keine andere Wahl bleibt, als die jeweilige OS-Komponente sofort zu entfernen und sie durch eine andere OSS-Komponente zu ersetzen oder gar in eigene Softwareentwicklung zu investieren. Hilfreich sind Prüfungen der gesamten Codebasis, ein enger Austausch mit den beteiligten Entwicklern und spezielle Software-Scanner.

Absprachen gewünscht

Schritt 3: Enge Absprachen mit den Entwicklerteams: Je größer, komplexer und verteilter die Projekte sind, desto schwieriger ist es, alle in genutzten Komponenten zu ermitteln. Auf die Frage: „Welche Open Source verwenden wir“ wird man allerdings wohl kaum eine erschöpfende Aufstellung erwarten dürfen. Das liegt auch daran, dass im Unternehmen oft in Vergessenheit gerät, welche OSS-Komponenten eigentlich genutzt werden. Zudem fehlt es vielen Entwicklern am nötigen Know-how was Open Source angeht.

Ein regelmäßiger Austausch mit Entwicklern, DevOps und IT-Mitarbeitern, die sich mit der Entwicklung, dem Deployment und der Durchführung des jeweiligen Software-Projekts befassen, ist daher unverzichtbar. Damit auch Module entdeckt werden, die im ersten Durchlauf übersehen wurden, sollten konkrete Fragen gestellt werden, zum Beispiel: „Welche Datenbank verwenden wir?“ oder „Welche Encription Libraries  nutzen wir?“.

Schritt 4: Management von Open Source Software sicherstellen: Für das Management von OSS-Nutzung sind einheitliche und für alle verpflichtende Prozesse zu etablieren. Nur so können Unternehmen die Lizenzvorschriften der genutzten Open Source Software einhalten und schnell auf neue Schwachstellen reagieren. Doch nicht jedes Entwicklerteam ist hinsichtlich Vollständigkeit und Compliance auf dem gleichen Stand. Es gibt Unternehmen, die lediglich die von den Entwicklern „angeforderten“ Komponenten nachverfolgen. Welche Komponenten nachverfolgt werden, hängt in solchen Szenarien zwangsläufig von der Sorgfalt der Entwickler ab.

Andere Unternehmen nutzen spezielle Scanner zur Ermittlung und Nachverfolgung der Software. Der Erfolg hängt dann vom Scanner oder vom Analyseumfang ab. Einige Tools erkennen nur den Lizenztext, nicht aber die eigentlichen OSS-Komponenten. Andere finden lediglich die von den Paketmanagern verwalteten Komponenten. Hier kommt es darauf an, auf welcher Ebene die Analysen durchgeführt werden und wonach gesucht werden soll. Üblicherweise wächst der Grad der Compliance phasenweise, je mehr Komponenten ermittelt und verwaltet werden.

Compliance nachweisen

Schritt 5: Compliance-Nachweis bei Softwarelizenzen: Zu wissen, dass auch bei Open Source lizenzrechtlichen Bestimmungen einzuhalten sind, reicht nicht aus. Es muss auch ein Nachweis der Compliance vorliegen. Befinden sich die erforderlichen Vermerke oder Urheberrechtshinweise im Produkt oder in der Dokumentation? Ist der Lizenztext wie gefordert angezeigt? Liegt für die unter Copyleft lizenzierten und im Unternehmen genutzten Inhalte ein schriftliches Angebot für den Quellcode oder die eigentlichen Quellcode-Distributionen vor? Wenn ja, sind das relevante Indikatoren eines effektiven Open Source-Managements.

Unternehmen, denen es gelingt Open Source-Komponenten in ihren Produkten nachzuverfolgen und ihre Mitarbeiter hinsichtlich der Nutzung von Dritt-Komponenten zu sensibilisieren, profitieren gleich doppelt: Sie verringern nicht nur das Risiko von Compliance-Verstößen, sondern können ihren Kunden auch sichere Produkte sowie langfristigen Support bieten.

Jeff Luszcz

ist Vice President of Product Management bei Flexera Software.

Hier geht es zu Flexera Software