132 lines
6.8 KiB
Markdown
132 lines
6.8 KiB
Markdown
<!--{"title": "Blogserie [1/5] Security by Community? Chancen und Risiken der Open-Source-Sicherheit", "date": "2025-05-11", "slug": "security-by-community-chancen-und-risiken-der-open-source-sicherheit", "description": "Viele Augen sehen mehr - das ist eines der häufigsten Argumente für die Sicherheit von Open-Source-Software.", "cover": "/static/img/security-by-community-chancen-und-risiken-der-open-source-sicherheit.webp"}-->
|
|
> Kennzeichnung gemäß Artikel 52 Absatz 1 EU AI Act: [💜 <ins>Kein Einsatz von KI</ins>](/page/ai)
|
|
|
|
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.
|
|
|