Open Source hat keinen Vertragspartner
Sie nutzen Open-Source-Software in Ihren Produkten und Systemen. Sie sind dafür regulatorisch verantwortlich. Aber Sie haben keinen Vertragspartner, der diese Verantwortung mit Ihnen teilt. Das ist das Delegations-Paradoxon der digitalen Lieferkette.
Das Problem #
In einer klassischen Lieferkette funktioniert Verantwortung durch Verträge: Sie vereinbaren mit Ihrem Zulieferer Qualitätsstandards, Reaktionszeiten, Haftungsregelungen und Eskalationswege. Wenn etwas schiefgeht, haben Sie einen Ansprechpartner und eine vertragliche Grundlage.
Bei Open Source existiert nichts davon:
- Sie können keine SLAs schließen. Es gibt niemanden, der Ihnen eine Reaktionszeit zusichert.
- Sie können keine Fristen setzen. Wenn eine Schwachstelle in einer Abhängigkeit auftaucht, können Sie den Maintainer bitten, sie zu beheben. Mehr nicht.
- Sie können keine Haftung übertragen. Open-Source-Lizenzen schließen Haftung und Gewährleistung in der Regel ausdrücklich aus.
- Sie haben keinen Einfluss auf die Entwicklung. Ob ein Projekt Ihre Sicherheitsanforderungen berücksichtigt, liegt nicht in Ihrer Hand.
- Sie haben keinen Eskalationsweg. Es gibt keinen Vorgesetzten des Maintainers, keine Beschwerdestelle, kein Vertragsstrafenmodell.
Gleichzeitig tragen Sie die volle Verantwortung. Die EU-Gesetzgebung macht hier keine Ausnahme für Open Source.
Wie groß ist die Lücke wirklich? #
Von über 7 Millionen untersuchten Open-Source-Komponenten (Stand 2024) haben weniger als 4.000 einen kommerziellen Support-Anbieter, bei dem Sie ein SLA abschließen könnten. Das sind unter 0,06 %.
Allein ein Linux-Server bringt bereits mehrere hundert Open-Source-Pakete mit - bevor Sie auch nur eine einzige eigene Anwendung installiert haben. Für die großen Endprodukte wie das Betriebssystem selbst, Ihre Datenbank oder Ihren Webserver existiert kommerzieller Support. Für die Masse der Abhängigkeiten, die diese Produkte und Ihre eigene Software mitbringen, gibt es keinen Anbieter, kein SLA und keinen Vertrag.
Was sagen die Gesetze? #
- DORA Art. 5 Abs. 2a: Das Leitungsorgan "trägt die letztendliche Verantwortung" für das IKT-Risikomanagement
- DORA Art. 28 Abs. 1: Finanzunternehmen bleiben "jederzeit voll verantwortlich" für IKT-Drittparteienrisiko
- NIS2 Art. 20 Abs. 1: Die Leitungsorgane müssen die Umsetzung von Cybersicherheitsmaßnahmen billigen und überwachen - persönlich
- § 38 Abs. 1 NIS2UmsuCG: Geschäftsleitungen sind verpflichtet, Maßnahmen umzusetzen und zu überwachen
- § 38 Abs. 2 NIS2UmsuCG: Geschäftsleitungen haften persönlich für schuldhaft verursachte Schäden
Die Verantwortung ist nicht delegierbar. Nicht an die IT-Abteilung, nicht an einen Dienstleister und schon gar nicht an einen Maintainer, der keine Verpflichtung Ihnen gegenüber hat.
Das Delegations-Paradoxon #
Vorstände und Geschäftsführer stehen vor einer Situation, die es in klassischen Lieferketten nicht gibt:
- Sie müssen die Risiken managen (gesetzliche Pflicht)
- Sie können die Risiken nicht an die Quelle delegieren (kein Vertragspartner)
- Sie dürfen die Verantwortung nicht einfach weitergeben (persönliche Haftung)
- Sie kennen die Risiken oft nicht einmal (weil die IT-Abteilung die SBOM noch nie angeschaut hat)
Das Ergebnis: eine persönliche Haftung für einen Zustand, den Sie nicht überblicken und nicht durch Verträge absichern können. D&O-Versicherungen decken Gesetzesverstöße typischerweise nicht ab - die Lücke bleibt bei Ihnen.
Was bedeutet das für Sie? #
Sie brauchen einen strukturierten Gegenpart für Ihre Open-Source-Lieferkette. Nicht jemanden, der Ihnen die Verantwortung abnimmt - das ist regulatorisch unmöglich. Sondern jemanden, der die Lücke zwischen "volle Verantwortung" und "null Einfluss" schließt: mit dokumentierten Prozessen, messbaren Ergebnissen und prüffähigen Nachweisen.
Weiterlesen #
OTTRIA schließt diese Lücke. Vereinbaren Sie ein Erstgespräch und erfahren Sie, wie.