Compliance: Die versteckten Risiken von Open-Source-Code

Jeff Luszcz * |

Anbieter zum Thema

Bis zu 50 Prozent des gesamten Code-Bestandes bestehen aus Open-Source-Software (OSS)-Komponenten. Für Softwareentwickler bedeuten sie mehr Agilität und Effizienz, doch sie bergen auch Risiken.

Open-Source-Software: Unternehmen sollten wissen, welche freien Code-Komponenten in ihren Produkten enthalten sind, um mögliche Compliance-Probleme minimieren oder ganz ausschließen zu können.
Open-Source-Software: Unternehmen sollten wissen, welche freien Code-Komponenten in ihren Produkten enthalten sind, um mögliche Compliance-Probleme minimieren oder ganz ausschließen zu können.
(Bild: © markus dehlzeit/Fotolia.com)

Unternehmen, die den Einsatz von Open Source nicht ordnungsgemäß verwalten, sehen sich hauptsächlich mit zwei Problemen konfrontiert: Sie verstoßen gegen die Compliance-Richtlinien der von ihnen genutzten Lizenzen und sie setzen sich dem Risiko unentdeckter Verwundbarkeiten aus, die sich möglicherweise in der Open-Source-Software befinden.

Das Copyleft-Prinzip

Unter Copyleft versteht man ein grundlegendes Konzept der Open Source-Community. Es besagt, dass Veränderungen und Weiterentwicklungen, die auf frei zugänglicher Software basieren, ebenfalls frei zugänglich sein müssen. Der freie Zugriff soll Innovationen fördern, indem die Community sämtliche Verbesserungen in eigene, wiederum frei zugängliche Projekte einfließen lassen kann. Inhaltlich und begrifflich steht das Copyleft dem Konzept des Copyright gegenüber, das die Urheber- und Verbreitungsrechte proprietärer Software schützt.

Mögliche Verstöße gegen Compliance-Richtlinien

Open-Source-Komponenten sind per Definition kostenlos und zur freien Nutzung – und doch gibt es Beschränkungen. Auch für OS-Komponenten gibt es Lizenzbedingungen, an die sich Entwickler in Unternehmen halten müssen.

Zu diesen Bestimmungen gehört typischerweise die Übermittlung des genauen Wortlautes der Lizenz, urheberrechtliche Erklärungen und – in manchen Fällen – sogar die Weitergabe des Quelltextes einzelner Komponenten oder des ganzen Produkts. Wenn ein Unternehmen nicht weiß, welche OSS genutzt wird, können diese Bedingungen nicht eingehalten werden.

Die Strafe für einen Verstoß kann, je nach Komponente, hart geahndet werden. Ein Beispiel ist der Prozess „Jacobsen gegen Katzer“ aus den USA, bei dem zum ersten Mal über eine Unterlassungsklage verhandelt wurde. In anderen Fällen musste das gesamte Softwareprodukt offengelegt werden, um den Compliance-Richtlinien zu entsprechen. Prominentestes Beispiel ist Cisco, das die Firmware für Linksys-Router öffentlich zugänglich machen musste.

Wenn Unternehmen keine Übersicht über die Komponenten Dritter behalten, können sie zudem nicht auf bekannte Verwundbarkeiten reagieren und dafür sorgen, dass diese Komponenten gepatcht, sicher und auf dem neuesten Stand sind. Folglich können alle aktuellen und zukünftigen Sicherheitslücken nicht entsprechend behoben werden.

Unentdeckte Schwachstellen und mangelndes Bewusstsein

Neue Vulnerabilities in OS-Komponenten werden sehr häufig erst nach deren Auslieferung entdeckt. Sie verstecken sich im ausgelieferten Produkt bis Angreifer sie ausnutzen und dem Unternehmen Daten entwenden oder finanziell schaden. Deswegen sollten gerade Unternehmen, im Security- und Netzwerkbereich genau wissen, welche Komponenten sie verwenden.

Viele Software-Verantwortliche sind sich der oben genannten Risiken nicht bewusst. Studien belegen, dass die meisten Unternehmen Mühe haben, eine Bill of Materials (BOM) oder eine Liste mit allen verwendeten Open Source-Komponenten zu erstellen. Selbst bei einer Firmenübernahme – einem Prozess, bei dem so viele Informationen wie möglich bereitgestellt werden sollen – kann der Großteil der Unternehmen nicht ein einziges Open Source-Projekt nennen, das verwendet wird.

Tabelle: Überblick über die zentralen Charakteristika der wichtigsten Open-Source-Lizenzmodelle
Tabelle: Überblick über die zentralen Charakteristika der wichtigsten Open-Source-Lizenzmodelle
(Bild: Flexera)

Selbst wenn eine Liste mit Komponenten existiert, stellt diese meist nur einen Bruchteil der verwendeten OSS dar: Im Schnitt werden nur fünf Prozent erfasst. Unternehmen, die nicht genau wissen, welche OSS sie nutzen, können auch nicht sicherstellen, die Risiken im Hinblick auf Compliance und Security zu minimieren.

Für viele Unternehmen zählen die Nachverfolgung und Verwaltung von Open Source nicht zu den grundlegenden Aufgaben. Beides rückt meist erst in den Fokus, wenn es zu einem unübersehbaren Problem kommt. Gibt es noch keine Regeln, sollten Unternehmen möglichst schnell Best Practices und automatische Prozesse implementieren, um OS-basierte Risiken nachhaltig zu senken.

Ein Open Source Review Board kann helfen

Der erste Schritt in jedem Open-Source-Management-Programm ist die Schulung der Mitarbeiter aller Entscheidungsebenen. Die Geschäftsführung muss sich der Compliance-Vorschriften bewusst sein und verstehen, warum regelmäßige Updates unabdingbar sind, wenn es um den Schutz angreifbarer OSS-Komponenten geht. Viele Unternehmen rufen deshalb ein Open Source Review Board (OSRB) ins Leben, in dem IT-Spezialisten, Juristen, Mitarbeiter aus technischen Fachbereichen und Führungskräfte vertreten sind.

Das OSRB erlässt Richtlinien, befasst sich mit Compliance- oder Sicherheitsfragen und sorgt für die Weiterbildung des restlichen Personals im Hinblick auf Open Source. Umgesetzt werden die Richtlinien dann von den Entwicklerteams. Das garantiert die Einhaltung aller OSS-Lizenzvereinbarungen und erlaubt die Einführung eines Prozesses, der Sicherheitslücken in Komponenten aufdeckt und Upgrades zur Verfügung stellt.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Zudem ermöglichten Management-Lösungen für Software Composition Analysis (SCA) ein effektives OSS-Management, das allen Compliance-Vorgaben entspricht. So können Unternehmen unter anderem eine BOM für jedes Software-Release erstellen, sämtliche Lizenzvereinbarungen einhalten und Updates für bereits verfügbare Produkte erstellen, sobald Schwachstellen entdeckt werden. So halten sich Unternehmen nicht nur an die Erwartungen der Community, sondern verringern auch das Risiko von OSS-basierten Sicherheitslücken.

* Jeff Luszcz ist Vice President of Product Management bei Flexera Software.

Artikelfiles und Artikellinks

(ID:44602393)