Wer pflegt das Fundament?

Ein großer Teil der digitalen Infrastruktur ruht auf Open-Source-Software, die von wenigen Menschen gepflegt wird – oft unbezahlt. Es gibt Software, von der kaum jemand je gehört hat, die aber fast überall läuft. Sie komprimiert Daten, parst Zeitangaben, prüft Zertifikate, liest Konfigurationsdateien. Sie steckt in Servern, Routern, Autos und Smartphones. Und nicht selten wird sie von einer Handvoll Menschen gepflegt, manchmal von einem einzigen – in den Abendstunden, nach dem eigentlichen Beruf.

Das ist kein neues Thema. Aber es ist eines, das sich leicht verdrängen lässt, solange alles funktioniert.

Ein Freitag im März 2024: die Hintertür in xz-utils

Am 29. März 2024 schrieb der Softwareentwickler Andres Freund eine Nachricht an die Mailingliste oss-security. Ihm war auf einem Testsystem aufgefallen, dass SSH-Anmeldungen ungewöhnlich viel Rechenzeit verbrauchten; seine Messung ergab rund 0,8 Sekunden statt zuvor etwa 0,3. Er ging der Sache nach und fand eine Hintertür in xz-utils, einer weit verbreiteten Kompressionsbibliothek. Die Versionen 5.6.0 und 5.6.1 waren manipuliert. Über Umwege – auf vielen Linux-Systemen ist die Bibliothek indirekt mit dem SSH-Server verbunden – griff der Schadcode in die Anmeldung per öffentlichem Schlüssel ein. Die Schwachstelle erhielt die Kennung CVE-2024-3094.

Dass die manipulierten Versionen weitgehend noch in Test- und Entwicklungszweigen steckten und nicht in den stabilen Ausgaben der großen Linux-Distributionen, war zu einem guten Teil Glück. Und der Aufmerksamkeit eines Einzelnen, der einer halben Sekunde misstraute.

Die eigentliche Geschichte

Technisch war die Hintertür raffiniert. Bemerkenswerter ist aber, wie sie ins Projekt kam. Spätere Rekonstruktionen, etwa die detaillierte Zeitleiste des Informatikers Russ Cox, zeichnen ein Bild über mehrere Jahre: Ab Oktober 2021 schickte eine Person unter dem Namen „Jia Tan“ zunächst kleine, hilfreiche Beiträge. Im Frühjahr und Sommer 2022 meldeten sich auf der Mailingliste mehrere Konten, die sich über das langsame Tempo des Projekts beklagten und darauf drängten, die Verantwortung zu teilen. Viele dieser Adressen tauchten nirgends sonst im Netz auf.

Der langjährige Maintainer Lasse Collin antwortete im Juni 2022 offen: Er habe das Interesse nicht verloren, aber seine Fähigkeit, sich zu kümmern, sei durch langfristige gesundheitliche Probleme eingeschränkt; das Projekt sei ein unbezahltes Hobby. Jia Tan erhielt nach und nach mehr Rechte und veröffentlichte im März 2023 erstmals selbst eine Version. Ein Jahr später folgte die Hintertür.

Man kann diese Geschichte als Lehrstück über Social Engineering lesen, und das ist sie auch. Aber sie ist vor allem eine Geschichte über Erschöpfung. Ein Mensch trägt allein ein Stück Software, auf das Millionen Systeme angewiesen sind, und bekommt dafür nichts – außer Druck. Wer in dieser Lage Hilfe angeboten bekommt, nimmt sie an. Das ist kein Versagen des Einzelnen. Es ist ein Versagen derer, die die Software nutzen, ohne je zu fragen, wer sie pflegt.

Gemeingut ohne Gemeinschaftskasse

Open-Source-Software ist ein Gemeingut: Jeder darf sie nutzen, niemand muss bezahlen. Das ist ihre Stärke. Sie senkt Kosten, ermöglicht Innovation, schafft Unabhängigkeit von einzelnen Herstellern. Unternehmen jeder Größe bauen ihre Produkte darauf.

Das Problem ist nicht, dass Unternehmen die Software kostenlos nutzen. Das ist ausdrücklich erlaubt und gewollt. Das Problem ist, dass die Pflege eines Gemeinguts nicht automatisch mitwächst, wenn seine Nutzung wächst. Eine Bibliothek kann über Jahre in immer mehr Produkte wandern, während die Zahl derer, die sie verstehen und weiterentwickeln, gleich bleibt – oder schrumpft.

Für Geschäftsführungen ist das eine unbequeme Einsicht: Ein Teil Ihrer Lieferkette besteht aus Menschen, mit denen Sie keinen Vertrag haben, die Sie nicht kennen und die Ihnen nichts schulden.

Was Unternehmen tun können

Die gute Nachricht: Man muss kein Technologiekonzern sein, um etwas beizutragen. Ein paar Wege, sortiert nach Aufwand.

Wissen, worauf man steht. Der erste Schritt ist ein Inventar der Open-Source-Komponenten in den eigenen Produkten und Systemen, idealerweise als Software-Stückliste (SBOM). Erst wer weiß, welche Projekte er nutzt, kann einschätzen, welche davon kritisch und schwach besetzt sind. Grundlagen dazu im Beitrag Open-Source-Lizenzen für Entscheider.

Geld geben – gezielt. Viele Projekte nehmen Spenden oder Sponsoring über Plattformen und Stiftungen an. Schon überschaubare, aber verlässliche Beträge können für einen einzelnen Maintainer viel bedeuten. Wichtiger als die Höhe ist die Verstetigung: ein fester Posten im Budget statt einer einmaligen Geste.

Arbeitszeit geben. Für viele Projekte ist Zeit wertvoller als Geld. Unternehmen können Beschäftigten erlauben, einen Teil ihrer Arbeitszeit für Projekte aufzuwenden, von denen das Unternehmen abhängt – Fehler beheben, Dokumentation verbessern, Code prüfen.

Upstream beitragen. Wer intern Fehler behebt oder Funktionen ergänzt, sollte diese Änderungen an das Ursprungsprojekt zurückgeben („upstream“). Das entlastet die Maintainer, und es erspart dem Unternehmen, eigene Abweichungen dauerhaft pflegen zu müssen.

Dienstleister einbeziehen. Wer Open Source über Distributoren oder Supportanbieter bezieht, sollte fragen, wie diese sich an der Pflege der zugrunde liegenden Projekte beteiligen. Auch das ist eine Form der Lieferkettenprüfung.

Öffentliche Initiativen kennen. In Deutschland investiert die vom Bund finanzierte Sovereign Tech Agency in offene digitale Basisinfrastruktur – mit Programmen etwa zur Finanzierung kritischer Projekte, zur Suche und Behebung von Schwachstellen und zur Unterstützung einzelner Maintainer. Für Unternehmen ist das kein Ersatz für eigenes Engagement, aber ein Hinweis darauf, wo die Lücken liegen.

Wie Unternehmen rund um Open Source wirtschaften und warum das für die Stabilität der Projekte wichtig ist, beschreibt unser Beitrag Wie Open-Source-Firmen sich finanzieren.

Der Gesetzgeber und die Verwalter

Auch die Europäische Union hat sich mit der Frage befasst, wer für Open-Source-Software verantwortlich ist. Der Cyber Resilience Act (Verordnung (EU) 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen zu Sicherheit über den gesamten Lebenszyklus. Wer Open-Source-Komponenten in seine Produkte einbaut, trägt dafür als Hersteller die Verantwortung – auch für die Sorgfalt bei der Auswahl und Pflege dieser Komponenten. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gelten seit dem 11. September 2026; die übrigen Pflichten ab dem 11. Dezember 2027.

Für die Open-Source-Welt selbst hat der CRA eine eigene Rolle geschaffen: den „Verwalter quelloffener Software“ (Open-Source Software Steward). Gemeint sind etwa Stiftungen oder Organisationen, die die Entwicklung von Open-Source-Software, die für kommerzielle Tätigkeiten bestimmt ist, dauerhaft unterstützen, ohne selbst Hersteller zu sein. Für sie gilt nach Artikel 24 ein bewusst leichteres Regime: Sie müssen eine nachvollziehbar dokumentierte Cybersicherheitsstrategie haben, die unter anderem den Umgang mit Schwachstellen regelt, und auf Anfrage mit den Marktüberwachungsbehörden zusammenarbeiten. Meldepflichten treffen sie nur, soweit sie an der Entwicklung beteiligt sind oder ihre eigenen Systeme betroffen sind. Geldbußen sind für Verwalter nach Artikel 64 ausdrücklich ausgeschlossen.

Das ist eine kluge Entscheidung. Sie erkennt an, dass Stiftungen und Communities keine Hersteller sind, und legt die Hauptlast dorthin, wo das Geld verdient wird: bei den Unternehmen, die Open Source in ihre Produkte einbauen und verkaufen. Gleichzeitig zeigt die Regelung, wo die Grenze des Gesetzes liegt. Einen einzelnen, unbezahlten Maintainer wie im Fall xz-utils erreicht kein Regelwerk. Ihn erreicht nur, wer bereit ist, Zeit oder Geld in sein Projekt zu stecken.

Dieser Abschnitt ersetzt keine Rechtsberatung.

Ein Fundament ist keine Selbstverständlichkeit

Man vergisst Fundamente, weil man sie nicht sieht. Das gilt für Gebäude, und es gilt für Software. Der Fall xz-utils war ein Weckruf – nicht, weil Open Source unsicher wäre; proprietäre Software hat ihre eigenen, oft schlechter sichtbaren Risiken. Sondern weil er gezeigt hat, dass Offenheit allein nicht genügt. Offener Code braucht Menschen, die ihn lesen, prüfen und pflegen. Und diese Menschen brauchen Zeit, Anerkennung und manchmal schlicht ein Einkommen.

Für Unternehmen, die über digitale Souveränität sprechen, ist das vielleicht die wichtigste Pointe: Souverän ist nicht, wer möglichst viel Open Source nutzt. Souverän ist, wer sich mitverantwortlich fühlt für das, worauf er baut. Was Souveränität darüber hinaus bedeutet, beschreibt unser Erklärstück Was digitale Souveränität bedeutet.

Die Frage, die sich jede IT-Leitung stellen kann, ist einfach: Welche drei Projekte tragen unser Geschäft, ohne dass wir je etwas zurückgegeben haben? Die Antwort ist der Anfang.