Blogserie [1/5] Security by Community? Chancen und Risiken der Open-Source-Sicherheit

Kennzeichnung gemäß Artikel 52 Absatz 1 EU AI Act: 💜 Kein Einsatz von KI

Open-Source ist in der IT-Welt kaum noch weg zu denken. Die Vielzahl an Projekten, welche zur engagierte Communities forangetrieben werden ist kaum zählbar. Fakt ist, viele kommerzielle Systeme verwenden, oder setzen sogar vollständig auf Open-Source-Entwicklungen auf. Das Grundprinzip ist, dass jeder den gesamten Code in Augenschein nehmen kann, diesen nach seinen Belieben verändern, oder auch am Ursprungsprojekt mitarbeiten kann.

Hierher resultiert der oft vertretene Konsens: Viele Augen sehen mehr, viele Hände erreichen mehr. In der Welt der IT-Sicherheit ist dies ein oft genanntes Argument für das Vertrauen in die Nutzung von Open-Source Software. Doch ist das in der Praxis wirklich so einfach?

Wir möchten in diesem Beitrag einen genauen Blick in diese Richtung werfen.

Was bedeutet Security by Community

Open-Source-Projekte werden von einer aktiven Gemeinschaft von Entwicklern gepflegt. Daher lasten auf dieser Community viele Herausforderungen:

Erstellen und Prüfen der Software-Entwicklung
Sicherheitslücken müssen schnell gefunden und behoben werden
Änderungen müssen gut organisiert, bewertet und trotzdem transparent bereitgestellt werden

Im Bestfall führt dies zu hohem Vertrauen innerhalb und außerhalb des eigenen Projektes, hoher Reaktionsgeschwindigkeit innerhalb des Proketes, sowie eines geteilten Verantwortung und einem hohen Maß an Sicherheit.

Wie immer ist das der Umstand unter den optimalen Bedingungen. Doch das ist nicht immer der Fall.

Warum Open-Source sicher sein kann

In der Welt der Software-Entwicklung ist nichts wichtiger, als Vertrauen in Stabilität und Sicherheit. Viele Projekte aus der Open-Source-Welt haben sich einen hervoragenden Ruf erarbeitet. Aber woran liegt das:

Transparenz

Im Gegensatz zu kommerziell vertriebener Software können Kunden und Organisationen selber prüfen, worauf sie sich einlassen.

Welche Sicherheitsmechanismen sind vorhanden
Gibt es Backdoors oder andere Bibliotheken, welche Abhängigkeiten erzeugen, die begutachtet werden müssen
In welchem Umfang und welcher Geschwindigkeit werden Bugs oder Schwachstellen behoben

Schnelle Reaktionszeiten

Gerade größere Open-Source-Projekte und deren Gemeinschaft haben oft ein breit aufgestelltes Know-How. Insbesondere sind diese oft extrem gut vernetzt und erfahren von Sicherheitsproblemen oft als Erste. In diversen Projekten sind eigene Security-Response-Teams im Einsatz, welche das Produkt und auftretende Sicherheitsprobleme binnen extrem kurzer Zeit bemerken und beheben.

Audits und Reviews

Viele dieser Projekte unterziehen sich freiwillig einer ganzen Reihe von Audits. Da dies in der Regel eine kostenintensive Maßnahme ist, finanzieren sich insbesondere größere Projekte durch eigene Stiftungen. Zu vermuten ist, dass sich dies in der Regel bezahlt macht.

Wo ist Open-Source verwundbar

Neben vielen Leuchtturm-Projekten hat auch die Welt der Open-Source ihr Schattenseiten.

Verwaiste Projekte

Nicht alle Open-Source-Projekte halten es lange durch. Einige Projekte werden nach einiger Zeit nicht mehr aktiv gepflegt. Zudem ist dies nicht immer direkt erkennbar. Dennoch werden diese Projekte regelmäßig in anderen Projekten als Abhängigkeiten weiter mitgeführt. In manchen Fällen ist auch die mangelhafte Dokumentation ein Problem. Dies kann ein potentielles Einfallstor für Angreifer sein.

Ein konkretes Beispiel ist die bekannte Schwachstelle von Log4J / Log4Shell

Supply-Chain-Risiken

Wie zuvor bereits kurz angerissen, stellt auch der Djungel von Abhängikeiten in der Welt von Open-Source-Software ein mögliches Risiko dar. Nicht immer ist klar, welche Projekte von einem Sicherheitsvorfall eines anderen Projektes unmittelbar betroffen sind. Oftmals sind ungepatchte Versionen in anderen Projekten noch einige Zeit im Umlauf.

Fehlende Zuständigkeiten

Wenn Open-Source-Projekte nicht gut verwaltet sind, herrscht of der Konsenz: Wenn alle verantwortlich sind, ist niemand verantwortlich. So können Fragen wie diese oft nicht beantwortet werden:

Welche Abhängigkeiten und in welcher Version werden verwendet
Wer Pflegt diese
Wer reagiert auf Sicherheitswarnungen

Relevanz für Unternehmen

Für den Einsatz in Unternehmen, Vereinen und Verbänden bedeutet Open-Source vor Allem: * Eigenverantwortung für das Sicherheitmanagement * Etablierten Prozess für die Auswahl, das Monitoring und die Updates von Open-Source-Software * Fortwährende Risikobewertung und überwachung von Sicherheitsbedrohungen

Best-Practices

Schulung von Entwicklern und Administratoren im Umgang mit Open-Source-Software
Etablieren einer Open-Source-Security-Policy

Relevanz für den öffentlichen Sektor

Anforderungen im ÖD

Für den öffentlichen Dienst gelten oft noch weitere Anforderungen:

Strikte Einhaltung von Datenschutz und Konformität zur DSGVO
Transparenzpflicht gegenüber dem Steuerzahler
Hohe Verfügbarkeitsanforderungen

Benefits für Open-Source-Projekte aus dem ÖD

Auch Open-Source-Projekte können von der verbreitung im öffentlichen Sektor profitieren:

Die Prüfung von Open-Source durch den öffentlichen Dienst kann durch Ausschreibung eine Zertifizierung oder ein Audit erhalten
Zunehmende Verbreitung durch Bildung von Kompetenzen in IT-Dienstleistern, welche am Projekt mitwirken

Fazit

Community ist gut, aber kein wirksamer Ersatz für eine gute Strategie. So funktionieren Open-Source-Projekte im Hinblick auf Sicherheit nur dann, wenn aktiv Verantwortung übernommen wird. Wer erwartet, das aus einer Masse an Entwicklern automatisch sichere Software entsteht, liegt hier leider falsch. Oftmals ist es auch eine Frage guter Finanzierung und Unterstützung. Aber das Protential ist vorhanden. Insbesondere im öffentlichen Sektor steckt viel Potential sich mit Hilfe von Open-Source auch frei von ausländischen Mega-Konzernen zu machen. Wer in Open-Source investiert, investiert nicht nur in ein Projekt, sondern meist auch in die gesamte Open-Source-Gemeinschaft.

Unternehmen und Behörden, welche Open-Source als strategischen Baustein verstehen, Anforderungen kommunizieren und sich in der Entwicklung einbringen, werden langfristig hiervon stark profitieren.

Im nächsten Beitrag unserer Serie vergleichen wir die verschiedenen Open-Source-Lizenzmodelle - und erklären, was Unternehmen und Verwaltungen bei der Nutzung beachten müssen.