Skip to main content

5 potenzielle Risiken von Open-Source-Software

Artikel von
blog hero software supply chain security

29. Juni 2021

0 Min. Lesezeit

Die Argumente für Open-Source-Software sind überzeugend. So überzeugend, dass sie inzwischen fester Bestandteil des Anwendungsentwicklungsprozesses ist.

Der kostenlose Zugang zu Bibliotheken, Frameworks und Prozessen erspart Unternehmen heute den Zeit- und Kostenaufwand, einen vollständigen Anwendungs-Stack von Grund auf neu zu entwickeln. Das beschleunigt die Entwicklung und fördert Innovationen.

Im Gegensatz zu proprietärer Software ist Open-Source-Code nicht verschleiert. Daher lässt sich die Codebasis leicht an die individuellen Anforderungen Ihres Unternehmens anpassen. Außerdem kann jeder Fehler finden und Korrekturen für Probleme im Code vorschlagen. So werden Probleme häufig schneller erkannt. In manchen Fällen ist Open-Source-Software dadurch robuster und sicherer als proprietäre Alternativen.

Risiken von Open-Source-Software

Bei der Auswahl von Projekten für Ihren Stack sollten Sie jedoch auch einige Risiken von Open-Source-Software berücksichtigen.

So kann es beispielsweise schwierig sein, bestimmte Bereitstellungen einzurichten und zu nutzen, wenn sie noch unausgereift oder unzureichend dokumentiert sind. Oder es treten aufgrund mangelnder Robustheit Probleme mit der Hardwarekompatibilität auf. In manchen Fällen müssen Sie sich außerdem bei einem kostspieligen Drittanbieter für Support anmelden, um technische Unterstützung zu erhalten.

In diesem Beitrag werfen wir einen genaueren Blick auf fünf Bereiche, die besonders bedenklich sind und die größten Risiken bei der Nutzung von Open-Source-Software darstellen.

  1. Softwarequalität

  2. Langfristige Nachhaltigkeit

  3. Softwarelizenzierung

  4. Urheberrechtsverletzungen

  5. Softwaresicherheit

1. Softwarequalität

Open-Source-Projekte sind in der Regel gemeinschaftlich ausgerichtet: Die Software wird durch gemeinsame Mitarbeit entwickelt, getestet und verbessert. Deshalb gelten sie oft als zuverlässiger als proprietäre Alternativen.

Allerdings gibt es keine Garantie – insbesondere dann nicht, wenn ein Projekt nur von einer Handvoll Beteiligter gepflegt wird.

Zudem unterscheiden sich die Mitwirkenden in Wissen, Fähigkeiten und Erfahrung. Manche können weniger Zeit einbringen als andere. Wie bei jedem Projekt mit unzureichenden Ressourcen leidet daher unweigerlich die Qualität.

Eine Möglichkeit, ein Open-Source-Projekt zu bewerten, besteht darin, Kennzahlen wie Wartungs- und Sicherheitsstatus zu betrachten. Wenn Sie diese Kriterien auswerten und ähnliche Open-Source-Projekte vergleichen, können Sie fundiertere Entscheidungen treffen. Mit Snyk Open Source Advisor finden und bewerten Sie ganz einfach die besten Open-Source-Pakete für Ihr Projekt. Das Tool deckt über eine Million Open-Source-Pakete ab.

Übersicht zu Snyk Advisor für das npm-Paket React v17.0.2 mit einem Health Score von 95/100, Sicherheitsstatus, Beliebtheit anhand der Downloads und Wartungsdiagrammen.
Übersicht zum Zustand des Open-Source-Pakets React auf Snyk Advisor

Anders als kommerzielle Software, für die es in der Regel eine Form von Garantie gibt, bieten nur sehr wenige Open-Source-Lizenzen einen solchen Schutz, falls die Software nicht wie erwartet funktioniert.

2. Langfristige Nachhaltigkeit

Viele Open-Source-Softwareprojekte werden von einer kleinen Gruppe von Mitwirkenden entwickelt. Als Freiwillige stehen sie oft unter dem Druck, ihre Projekte zu pflegen und gleichzeitig einer Vollzeitbeschäftigung nachzugehen.

Das kann zu Open-Source-Burnout führen: Ein Projekt stagniert, weil die Mitwirkenden ihr Engagement nicht aufrechterhalten können – bis es schließlich ganz eingestellt wird.

Wenn Sie auf Open-Source-Komponenten angewiesen sind, die nicht mehr gepflegt werden, müssen Sie möglicherweise selbst Sicherheitslücken und andere Codefehler beheben. Achten Sie daher darauf, wie oft Projekte aktualisiert werden.

3. Softwarelizenzierung

Die meiste Open-Source-Software ist zwar kostenlos nutzbar, aber praktisch jede ist in irgendeiner Form lizenziert.

Derzeit gibt es über 100 von der OSI anerkannte Open-Source-Lizenzen. Ein komplexer Anwendungs-Stack oder eine Entwicklungsumgebung kann daher einer verwirrenden Vielzahl von Open-Source-Lizenzvereinbarungen unterliegen – manche davon sind sehr komplex und detailliert.

Infografik zum Vergleich von fünf Softwarelizenztypen – von Public Domain bis proprietär – auf einer Skala zunehmender Einschränkungen.
Die 5 Arten von Softwarelizenzen

Open-Source-Lizenzen lassen sich grundsätzlich in zwei Kategorien einteilen: permissive Lizenzen und Copyleft-Lizenzen.

  • Permissive Lizenzen wie die MIT License erlauben Ihnen im Allgemeinen, den Code nach Belieben zu nutzen. Außerdem können Sie den Code in Ihre eigenen proprietären Anwendungen integrieren und abgeleitete Software verbreiten – sofern Sie den ursprünglichen Urheber nennen.

  • Copyleft-Lizenzen wie die GNU General Public License und die Server Side Public License (SSPL) gestatten Ihnen ebenfalls, den Code nach Belieben zu ändern. Wenn Sie ihn jedoch weiterverwenden und verbreiten möchten, müssen Sie den neuen Quellcode kostenlos zur Verfügung stellen. Das kann besonders problematisch sein, wenn Sie Copyleft-lizenzierte Komponenten in Ihre proprietäre Software integrieren möchten. Möglicherweise müssen Sie Ihren eigenen Code offenlegen, um die Softwarelizenz einzuhalten.

Eine Möglichkeit, Lizenzprobleme zu vermeiden, ist eine Liste genehmigter Open-Source-Komponenten sowie ein Verzeichnis der in Ihren Systemen verwendeten Open-Source-Software. Auch Open-Source-Richtlinien tragen dazu bei, die Einhaltung der Lizenzbedingungen sicherzustellen.

Gleichzeitig sollten Sie technische Aspekte berücksichtigen, etwa wie verschiedene Anwendungen und Services miteinander interagieren, bevor Sie sich für Open-Source-Komponenten entscheiden. Bedenken Sie außerdem, dass Sie Ihre Anwendungen möglicherweise irgendwann auch dann veröffentlichen möchten, wenn sie zunächst nur intern genutzt werden.

Achtung:

Ein großer Teil der frei verfügbaren Software auf Entwicklungsplattformen wie GitHub hat überhaupt keine Lizenz.

In vielen Ländern ist Anwendungscode jedoch automatisch standardmäßig durch ein ausschließliches Urheberrecht geschützt. Nur weil er öffentlich zugänglich ist, bedeutet das nicht, dass Sie ihn verwenden dürfen. Mit anderen Worten: Sie sollten solche Software nicht verwenden, es sei denn, Sie haben die Erlaubnis dazu.

4. Urheberrechtsverletzungen

Viele Open-Source-Entwickler sind Hobbyisten. Oft sind sie auf sich allein gestellt und verstehen das Konzept des geschützten geistigen Eigentums möglicherweise nicht – oder respektieren es nicht.

Dadurch besteht das Risiko von Urheberrechtsverletzungen: Unerfahrene oder nachlässige Programmierer können dazu führen, dass proprietärer Code (oder Copyleft-Code) in ein Projekt gelangt. Open-Source-Lizenzen übernehmen daher keine Verantwortung für Urheberrechts- oder andere Verletzungen geistigen Eigentums.

Prüfen Sie daher sorgfältig, bevor Sie Open-Source-Software einsetzen. So vermeiden Sie mögliche rechtliche Schritte und daraus resultierende Schadensersatzforderungen.

5. Softwaresicherheit

Aufgrund ihres gemeinschaftlichen und transparenten Charakters hat Open-Source-Software im Allgemeinen einen besseren Ruf in puncto Softwaresicherheit als proprietäre Software.

Wird eine Sicherheitslücke in einer kommerziellen Anwendung entdeckt, müssen Sie auf die Reaktion des Anbieters warten. Bei Open-Source-Software ist dagegen häufig jemand zur Stelle, der sie sofort beheben kann.

Das ist jedoch nicht immer der Fall – insbesondere bei kleineren Projekten.

Außerdem verfügen fast die Hälfte aller Open-Source-Projekte nach wie vor nicht über festgelegte Sicherheitsaudit-Verfahren.

Sie sollten sich also nicht einfach darauf verlassen, dass alle Mitglieder der Open-Source-Community ihre Projekte kontinuierlich auf Probleme mit der Open-Source-Sicherheit überprüfen.

Zudem ist es alles andere als einfach, den Überblick über die neuesten Software-Updates, Patches und noch nicht behobenen Sicherheitslücken zu behalten.

Sie können beispielsweise die Feeds verschiedener Datenbanken mit bekannten Sicherheitslücken abonnieren, darunter die Sicherheitslücken-Datenbank von Snyk. Doch selbst die größten und umfassendsten Services wie die National Vulnerability Database (NVD) führen nicht alle gemeldeten Probleme auf.

Beachten Sie außerdem, dass diese Services Updates in der Regel mehrere Wochen zurückhalten. So erhalten Open-Source-Entwickler Zeit, eine Sicherheitslücke zu diskutieren, zu beheben und zu testen, bevor sie öffentlich gemacht wird.

Dieser Ansatz ist zwar sinnvoll, verschafft Hackern mit Insiderwissen jedoch mehr Zeit, einen Angriff zu planen und durchzuführen. Und selbst wenn Nutzer über eine Sicherheitslücke informiert werden, patchen manche zu spät – oder wissen im schlimmsten Fall gar nicht, dass sie die betroffene Komponente verwenden.

State of Open Source Security 2022

A look at software supply chain complexity and risk in collaboration with the Linux Foundation.

Bleiben Sie einen Schritt voraus

Trotz der weithin anerkannten Vorteile von Open-Source-Software sollten Sie sich gründlich informieren, um die passende Lösung für Ihr Unternehmen auszuwählen.

Sie benötigen aber auch Tools, mit denen Sie Ihre Bereitstellungen verwalten können. Diese sollten Ihnen einen klaren Überblick über Ihr Open-Source-Inventar verschaffen. So behalten Sie den Überblick über alle Frameworks und Bibliotheken, die Sie in Ihren Anwendungen verwenden, und können die Anforderungen von Open-Source-Lizenzen einhalten.

Suchen Sie außerdem nach Lösungen, die Sie dabei unterstützen, die Anwendungssicherheit im Blick zu behalten, indem sie Open-Source-Sicherheitslücken frühzeitig erkennen, bevor Angreifer sie ausnutzen können.

Wenn Sie Ihre Open-Source-Nutzung sorgfältig verwalten und mögliche Sicherheitsrisiken sowie rechtliche Fallstricke besonders berücksichtigen, können Sie die Vorteile des Open-Source-Modells nutzen und zugleich das Risiko kostspieliger Probleme in der Zukunft minimieren.

Ohne Unterstützung durch automatisierte Sicherheits- und Governance-Tools müssen Sie jedoch viel manuelle Arbeit investieren, um die Einhaltung von Lizenzbedingungen und die neuesten Sicherheitslücken in Paketen im Blick zu behalten.

Starten Sie mit Capture-the-Flag

Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Challenges lösen.

Weiterlesen

blog feature snyk container custom base recommendations
Blog

Evo Agentic AppSec: Sicherheit, die mit der KI-Entwicklung Schritt hält

KI-gestützte Entwicklung überholt herkömmliche Security-Workflows. Snyk Agentic AppSec setzt Security-Agenten ein, die Schwachstellen kontinuierlich finden, beheben und überprüfen – während Menschen die Maßstäbe festlegen.

feature insights context
Blog

Autonome Angriffe sind bereits Realität. Die Verteidigung muss Schritt halten.

Autonome Angreifer verkürzen das Zeitfenster für die Verteidigung. Erfahren Sie, wie kontinuierliches Erkennen, Beheben, Validieren und Verhindern Sicherheitsteams helfen kann, Schritt zu halten.

feature insights context
Blog

Ist Prävention im Grunde ein gelöstes Problem?

Die Prävention in von Agenten generiertem Code ist architektonisch gelöst – die Herausforderung besteht jedoch weiterhin darin, Kontrollen zu wählen, die die Sicherheit schützen, ohne die Entwicklung zu verlangsamen.