Open Source finanzieren ist Cybersicherheit — warum Unternehmen ihre digitale Lieferkette mittragen sollten

Wenn beim nächsten npm install die Zeile „142 packages are looking for funding” erscheint, scrollt sie bei den meisten Entwicklern wortlos vorbei. Dabei steckt in diesem unscheinbaren Hinweis eine Frage, die jedes Unternehmen etwas angeht — und zwar nicht nur als nette Geste, sondern als handfeste Frage der eigenen Cybersicherheit.

Die unsichtbare Lieferkette

Kaum ein Unternehmen schreibt seine Software heute noch von Grund auf selbst. Webseiten, Apps, interne Tools, Build-Pipelines — sie alle bestehen zu großen Teilen aus Open-Source-Komponenten. Studien zur Software-Zusammensetzung gehen seit Jahren davon aus, dass moderne Anwendungen zu 80–90 Prozent aus fremdem, quelloffenem Code bestehen. Der eigene Code ist nur die dünne Schicht obendrauf.

Das gilt besonders für sicherheitskritische Funktionen. Verschlüsselung, Authentifizierung, das Parsen von Eingaben, das Verarbeiten von Dateiformaten — vieles davon läuft über etablierte Open-Source-Bibliotheken. Und das ist auch richtig so: Niemand sollte seine eigene Kryptografie schreiben. Aber es bedeutet auch: Die Sicherheit Ihres Unternehmens hängt am Zustand von Software, die Sie nicht selbst kontrollieren.

Getragen von wenigen Schultern

Der entscheidende Punkt ist, wer diese Software pflegt. Die Vorstellung, hinter jedem wichtigen Open-Source-Projekt stünde eine große Organisation, ist ein Trugschluss. In Wahrheit werden viele kritische Bausteine von einzelnen Personen oder winzigen Teams gepflegt — oft ehrenamtlich, in der Freizeit, ohne Bezahlung.

Drei Vorfälle haben das schmerzhaft sichtbar gemacht:

• Heartbleed (2014): Eine schwere Lücke in OpenSSL — der Bibliothek, die einen Großteil der verschlüsselten Internet-Verbindungen absichert. Damals wurde sie von einer Handvoll Leuten mit einem Mini-Budget gepflegt.
• Log4Shell (2021): Eine der folgenschwersten Schwachstellen überhaupt, in der Java-Bibliothek Log4j — gepflegt von Freiwilligen, die über Nacht zur Notfall-Mannschaft der halben IT-Welt wurden.
• Die xz-utils-Backdoor (2024): Hier wurde es besonders perfide. Ein überlasteter Einzel-Maintainer wurde über Jahre hinweg sozial manipuliert, bis ein eingeschleuster Mitstreiter eine Hintertür in ein Kompressionswerkzeug einbaute, das tief in zahllosen Linux-Systemen steckt.

Die Lehre aus xz-utils ist die unbequemste: Ein erschöpfter, allein gelassener Maintainer ist selbst ein Sicherheitsrisiko. Wer keine Zeit, kein Geld und keine Mitstreiter hat, kann Code nicht sorgfältig prüfen, Schwachstellen nicht schnell schließen und Manipulationsversuche schlechter erkennen.

Förderung ist eine Sicherheitsmaßnahme

Genau hier schließt sich der Kreis. Wenn die Sicherheit Ihres Unternehmens auf Open-Source-Projekten ruht, dann ist die Gesundheit dieser Projekte Teil Ihres eigenen Risikoprofils. Ein gut finanziertes Projekt kann sich Code-Reviews leisten, Sicherheitsaudits beauftragen, Schwachstellen zügig beheben und Maintainer entlasten, bevor sie ausbrennen.

Geld, das in die Pflege Ihrer digitalen Lieferkette fließt, ist kein Sponsoring — es ist eine Investition in die Stabilität Ihrer eigenen Systeme.

Das passt auch zum regulatorischen Trend: NIS-2 und der neue C5:2026-Katalog des BSI rücken die Lieferkettensicherheit ausdrücklich in den Vordergrund. Wer Lieferkettenrisiken ernst nimmt, kann die Open-Source-Komponenten darin nicht ausklammern — und Förderung ist eines der wenigen wirksamen Instrumente, die Nutzern überhaupt zur Verfügung stehen.

Was Unternehmen konkret tun können

1. Sichtbar machen, worauf Sie aufbauen: Der Befehl npm fund (oder das Pendant Ihres Ökosystems) zeigt, welche Projekte in Ihrem Stack um Unterstützung bitten. Das ist der ehrlichste Einstieg.
2. Ein Budget einplanen: Schon ein kleiner, fester Posten im IT-Budget für Open-Source-Förderung macht einen Unterschied — gerade bei Projekten mit großer Wirkung und wenigen Maintainern.
3. Den richtigen Kanal wählen: Plattformen wie OpenCollective bieten transparente Finanzen und stellen Unternehmen ordentliche Rechnungen aus — das erleichtert die Verbuchung. GitHub Sponsors eignet sich gut, um einzelne Maintainer direkt zu unterstützen.
4. Priorisieren nach Hebelwirkung: Fördern Sie dort, wo viel Last auf wenigen Schultern liegt — kritische, breit genutzte Bibliotheken, die von Einzelpersonen gepflegt werden.
5. Auch nicht-finanziell beitragen: Fehlerberichte, Sicherheitsmeldungen über die richtigen Kanäle, Dokumentation, das Freigeben von Arbeitszeit der eigenen Entwickler — auch das stärkt Projekte.

Fazit

Open Source ist kein Gratis-Selbstbedienungsladen, sondern eine gemeinsam getragene Infrastruktur. Unternehmen, die täglich davon profitieren — und ihre Sicherheit darauf aufbauen — sollten einen Teil dazu beitragen, dass diese Infrastruktur gesund bleibt. Das ist keine Wohltätigkeit. Es ist vorausschauendes Risikomanagement.

Die nächste „packages are looking for funding”-Zeile ist eine gute Gelegenheit, einmal hinzuschauen.

Sie möchten die Open-Source-Komponenten in Ihrer Lieferkette bewerten und absichern? Kontaktieren Sie uns für eine unverbindliche Ersteinschätzung.