Lizenzmanagement bei Open Source Software in der öffentlichen Verwaltung

Software besteht zu bis zu 50 Prozent aus Open-Source-Programmcode. Das erhöht die Agilität und Effizienz in der Softwareentwicklung, bringt aber auch versteckte Compliance- und Sicherheitsrisiken mit sich. Zwar sind OSS-Komponenten per Definition kostenlos und frei verfügbar, trotzdem gelten die jeweiligen Lizenzbestimmungen. In der Realität zeigt sich, dass nur ein kleiner Prozentsatz dieser Bestimmungen tatsächlich erfüllt wird.

Dabei weichen die Angaben der Softwareanbieter von der tatsächlichen Nutzung üblicherweise um den Faktor 20 ab. Oft wird die Problematik erst bei Fusionen und Übernahmen, beim Austausch mit OEMs oder bei Anfragen großer Unternehmen offensichtlich, wenn es darum geht Open-Source- wie kommerziellen Code offenzulegen und von unabhängiger Seite verifizieren zu lassen.

Softwarehersteller, denen der Überblick über den Einsatz von Komponenten Drittanbieter fehlt, sind zudem kaum in der Lage, auf gemeldete Schwachstellen zu reagieren und Patches und Updates in kürzester Zeit zur Verfügung zu stellen. Das Sicherheitsrisiko ist gewaltig, und die rechtlichen wie finanziellen Folgen von Hackerangriffen und Daten-Leaks kaum abzusehen.

Mehr Transparenz durch offenen Quellcode

Richtig eingebunden, nachverfolgt und dokumentiert verspricht der Einsatz von Open Source allerdings ein hohes Maß an Transparenz. Insbesondere bei sicherheitskritischen Anwendungen im öffentlichen Bereich lautet die Forderung, Software entweder unter einer Open-Source-Lizenz bereitzustellen oder zumindest den Quellcode zur Überprüfung offenzulegen. So sind IT-Experten in der Lage den Code auf Sicherheitslücken, algorithmische Verzerrungen oder Fehler zu überprüfen und eventuelle Compliance-Verstöße aufzudecken.

Wie dringlich eine solche Überprüfung ist, zeigt ein Beispiel der Bundestagswahl 2017. Der Chaos Computer Club (CCC) warnte in einer Analyse (PDF) vor erheblichen Sicherheitslecks in einer häufig eingesetzten Wahl-Software und forderte als Mindestmaßnahme die Veröffentlichung jeglicher Wahlhilfsmittel-Software als Published Source mit öffentlichem Lese-Zugang auf die verwendeten Source-Code-Revisioning-Systeme. Die Sicherheit der Software könne auch bei Veröffentlichung durch entsprechende Verfahren problemlos gewährleistet werden.

Softwarehersteller in der Pflicht

Das stellt Softwarehersteller vor neue Herausforderungen: So haften Unternehmen beim Vertrieb ihrer Softwareprodukte für die Einhaltung der Lizenzbestimmungen. Das gilt für undokumentierte Software Dependencies wie auch für über die Software Supply Chain eingeführte Komponenten. Die letztliche Verantwortung liegt beim Hersteller – egal ob es sich um die Programmierung der eigenen Entwickler oder um Software Development Kits, Komponenten, Betriebssysteme sowie andere ausführbare Dateien Dritter handelt.

In Folge werden Open-Source-Compliance-Anforderungen immer häufiger in Lieferantenvereinbarungen festgeschrieben, um Weiterleitungsverpflichtungen wie Lizenztexte und Quellcodebündel zu erhalten und eine ordnungsgemäße und zeitnahe Verwaltung von Abhängigkeiten sicherzustellen. Damit wird allen Beteiligten der Lieferkette die Wichtigkeit von Open-Source-Compliance vor Augen geführt. Zudem lässt sich in den Verträgen eine explizite Dokumentation aller Schwachstellen sowie Verfahren beim Umgang mit Warnmeldungen und Upgrades festlegen.

Vorbereitung auf Reviews

Um künftige Anforderungen erfüllen zu können, sollten Softwareanbieter Strategien entwickeln, um bestehende Softwarepakete entweder als Open-Source-Projekt zu öffnen oder als proprietäres Paket bereitzustellen. Dieser Prozess umfasst typischerweise zwei Prozesse.

Zunächst gilt es einen Freigabeprozess hinsichtlich geistigen Eigentums und Open Source einzuführen. Dabei wird die bestehende Anwendung auf die ordnungsgemäße Lizenzierung aller Open-Source- und kommerziellen Softwarekomponenten überprüft und in einem Offenlegungsdokument entsprechend aufgeführt. Findet sich ein Lizenzverstoß, muss dieser behoben oder die betroffene Komponente entfernt und ihre Funktionalität durch eine konforme Komponente ersetzt werden.

Bei veralteten Versionen von Softwarepaketen gilt es, Updates durchzuführen und eventuelle Schwachstellen zu beseitigen. Soll das Produkt als Open Source zur Verfügung stehen, wird über die endgültige Lizenz des Pakets festgestellt, welche anderen Open-Source- oder kommerziellen Komponenten mit dem für das Paket ausgewählten Lizenzsystem kompatibel sind.

Im weiteren Verlauf wird eine separate Sicherheitsüberprüfung veranlasst. Diese dient dazu, Schwachstellen im Quellcode des Produkts oder im Sicherheitsmodell für die gesamte Anwendung aufzudecken. Auf diese Weise wird die proprietäre Anwendung sowohl für Open Sourcing als auch für Reviews durch Dritte vorbereitet. Alle Probleme in Bezug auf geistiges Eigentum oder Sicherheitsprobleme können an dieser Stelle behoben werden.

Dieser Prozess kann Wochen bis Monate dauern und sollte daher gut geplant sein. Hilfestellung bieten externe Experten – sowohl bei der technischen Durchführung als auch beim Austausch mit der Open-Source-Community.

Der Forderung nach mehr Transparenz und Offenlegung nachzugehen, heißt etablierte Prozesse zu implementieren, die es erlauben, Open Source- wie kommerzielle Komponenten in Softwareprodukten zu scannen, nachzuverfolgen und zu managen. Nur so können Softwareanbieter das hohe Maß an Sicherheit garantieren, das für sicherheitskritische Anwendungen – im öffentlichen Sektor, in der Industrie oder im Unternehmen – nötig ist.

Tipp: Wie gut kennen Sie sich mit Open Source aus? Überprüfen Sie Ihr Wissen – mit 15 Fragen auf silicon.de.