Open Source · Lieferkette · Maintainer
Die Open-Source-Bibliothek, die euren Stack trägt, hat vielleicht nur einen Maintainer
Fast jede Anwendung, die ihr ausführt, hängt von Open-Source-Bibliotheken ab, und diese Bibliotheken hängen von weiteren ab, mehrere Schichten tief. Was leicht vergessen wird, ist, wie viele dieser Schichten von ein bis zwei unbezahlten Freiwilligen gepflegt werden. Wenn ein solches Projekt kritisch und unterversorgt ist, wird es zu einem einzelnen Ausfallpunkt - für die Zuverlässigkeit und, wie die jüngere Geschichte zeigt, für die Sicherheit.
Das Bild, das xkcd genau richtig traf
2020 zeichnete der xkcd-Comic 2347 mit dem Titel „Dependency" die moderne digitale Infrastruktur als einen prekären Turm aus Blöcken, wobei die gesamte Struktur auf einem kleinen Stück ruht, das als ein Projekt beschriftet ist, das „irgendeine zufällige Person in Nebraska seit 2003 undankbar pflegt". Er wurde zum sofortigen Klassiker unter Entwicklern, weil er weniger ein Witz als ein exaktes Diagramm ist. Der Abhängigkeitsbaum eines typischen Projekts läuft an manchen Stellen tatsächlich auf die Freizeitarbeit einer einzigen Person hinaus.
Als der Turm wirklich wankte
Das sind keine hypothetischen Risiken. Einige gut dokumentierte Vorfälle machen das Muster konkret:
- Heartbleed (2014). Ein schwerwiegender Fehler in OpenSSL, der Bibliothek, die einen Großteil des HTTPS-Verkehrs des Webs absichert, legte Speicher offen, der Schlüssel und Passwörter durchsickern lassen konnte. Damals wurde OpenSSL von einer winzigen Gruppe mit minimaler Finanzierung gepflegt. Der Schrecken löste direkt Finanzierungsbemühungen der Industrie für kritische Open-Source-Infrastruktur aus.
- Log4Shell (Dezember 2021). Ein kritischer Fehler zur Remote-Code-Ausführung in Log4j, einer Logging-Bibliothek, die in unzählige Java-Anwendungen eingebettet ist, wurde mit der höchsten Schweregradstufe bewertet. Log4j wurde von einem kleinen Team von Freiwilligen gepflegt, das dann eine erschöpfende Zeit damit verbrachte, ein Problem zu beheben, das einen riesigen Anteil der Unternehmenssoftware betraf.
- Die xz-utils-Hintertür (2024). Das ist die deutlichste Warnung von allen. Laut öffentlichem Bericht (CVE-2024-3094, bewertet mit CVSS 10.0) verbrachte ein Mitwirkender unter dem Namen „Jia Tan" rund zwei Jahre damit, Vertrauen im xz-Komprimierungsprojekt aufzubauen, erlangte Commit- und dann Release-Manager-Rechte, während der langjährige alleinige Maintainer, Lasse Collin, unter Druck stand und Berichten zufolge ausgebrannt war. Schädlicher Code wurde in xz 5.6.0 und 5.6.1 eingeschleust, der die von SSH auf einigen Linux-Distributionen genutzte Bibliothek mit einer Hintertür versah. Er wurde fast zufällig entdeckt, vor einer breiten Verteilung, von einem Ingenieur, der untersuchte, warum Anmeldungen etwas langsam waren.
Warum ein einzelner Maintainer ein strukturelles Risiko ist
Ein Projekt mit einem einzigen Maintainer bündelt mehrere Risiken an einem Ort. Wenn der Maintainer das Interesse verliert, krank wird oder einfach ausbrennt, bleiben Updates und Sicherheitskorrekturen aus - das „Abandonware"-Problem. Ist er überlastet, schafft der Druck, die Kontrolle abzugeben, eine Öffnung für einen böswilligen Akteur, was genau der Fall xz-utils ausnutzte. Und da so viele nachgelagerte Projekte die Bibliothek transitiv einziehen, breitet sich ein Problem an der Wurzel auf alles darüber Gebaute aus, oft ohne dass diese nachgelagerten Teams überhaupt wissen, dass die Abhängigkeit vorhanden war.
Die unbequeme Wahrheit ist, dass die Nachhaltigkeit von Open Source ein wirtschaftliches Problem in technischem Gewand ist. Der Code ist kostenlos; die menschliche Aufmerksamkeit, die ihn sicher hält, ist es nicht, und sie ist häufig unbezahlt.
Was Teams wirklich tun können
Ihr könnt nicht jede Abhängigkeit persönlich pflegen, aber ihr könnt aufhören, sie als kostenlose Infrastruktur zu behandeln, die sich selbst wartet:
- Kennt euren Abhängigkeitsbaum. Erstellt eine Software-Stückliste (SBOM), damit ihr wirklich wisst, was ihr ausliefert, einschließlich der transitiven Abhängigkeiten, die ihr nie direkt gewählt habt.
- Achtet auf den Bus-Faktor. Prüft bei den Bibliotheken, auf die ihr euch am meisten verlasst, wie viele aktive Maintainer es gibt. Eine kritische Abhängigkeit mit einem einzigen Mitwirkenden ist ein Risiko, das zu protokollieren, nicht zu ignorieren ist.
- Pinnt und prüft Updates. Pinnt Versionen und prüft Änderungen, statt blind die neueste Version zu ziehen; die xz-Hintertür kam in einer normal aussehenden Version.
- Gebt dort zurück, wo es zählt. Projekte, von denen ihr abhängt, zu sponsern, zu finanzieren oder Wartungszeit beizusteuern, ist keine Wohltätigkeit - es senkt euer eigenes Risiko. Branchenfonds und Stiftungen existieren nun teils aus diesem Grund.
Nichts davon beseitigt das Risiko vollständig, aber es verwandelt eine unsichtbare Abhängigkeit in eine verwaltete. Die Projekte, die euren Stack tragen, sind es wert, beim Namen gekannt zu werden.
FAQ
Ist Open Source unsicherer als Closed Source? Nicht von Natur aus - offener Code kann von jedem geprüft werden, was ein echter Vorteil ist. Das hier besprochene Risiko betrifft Ressourcen und Wartung, nicht die Offenheit selbst. Unterfinanzierte Software jeder Art ist ein Risiko.
Was ist der „Bus-Faktor"? Es ist die Anzahl der Personen, die von einem Bus erfasst werden müssten (oder einfach gehen), bevor ein Projekt in ernste Schwierigkeiten gerät. Ein Bus-Faktor von eins bedeutet, dass eine einzelne Person das Projekt ist.
Was war die xz-utils-Hintertür? Eine absichtlich platzierte Hintertür (CVE-2024-3094), eingefügt von einem Mitwirkenden, der sich mit der Zeit Maintainer-Vertrauen erarbeitet hatte, 2024 entdeckt, bevor sie die meisten Produktionssysteme erreichte. Sie ist das Referenzbeispiel für Social Engineering an einem Projekt mit einem einzigen Maintainer.
Wie finde ich Abhängigkeiten mit einem einzigen Maintainer? Beginnt mit einer SBOM eures Projekts, schaut euch dann die Repositories eurer kritischsten Bibliotheken an: die jüngste Commit-Aktivität und die Zahl der aktiven Maintainer sagen viel aus.