Open-Source-Lieferkettensicherheit

Ihre Software besteht zu einem erheblichen Teil aus Open-Source-Komponenten. Diese Komponenten bilden eine Lieferkette - und diese Lieferkette hat Risiken, die sich grundlegend von denen klassischer Zuliefererbeziehungen unterscheiden.

Warum ist die Open-Source-Lieferkette anders? #

Bei einem klassischen Zulieferer haben Sie einen Vertrag, einen Ansprechpartner, vereinbarte Qualitätsstandards und Haftungsregelungen. Bei Open Source haben Sie nichts davon. Die Software wird von Einzelpersonen oder kleinen Gruppen bereitgestellt, oft ohne jede Verpflichtung gegenüber den Nutzern.

Das bedeutet: Sie nutzen Software, für die niemand Ihnen gegenüber verantwortlich ist - aber Sie sind gegenüber Ihren Kunden, Aufsichtsbehörden und Geschädigten voll verantwortlich.

Die fünf zentralen Risiken #

1. Verwaisung Ein Projekt wird nicht mehr gepflegt. Der Maintainer hat aufgehört, ist ausgebrannt oder hat das Interesse verloren. Schwachstellen werden nicht mehr behoben. Updates kommen nicht mehr. Ihre Abhängigkeit bleibt bestehen.

2. Löschung Ein Maintainer löscht sein Projekt - aus Frustration, wegen eines Streits oder aus anderen Gründen. Ihre Build-Pipeline bricht. Schlimmer: Jemand anderes registriert denselben Paketnamen und schleust Schadcode ein.

3. Lizenzwechsel Ein Projekt wechselt seine Lizenz - von permissiv zu restriktiv oder zu proprietär. Plötzlich dürfen Sie die Software nicht mehr so verwenden wie bisher, oder es entstehen unerwartete Kosten.

4. Supply-Chain-Angriffe Ein Angreifer übernimmt ein Projekt - durch Social Engineering, durch Kauf des Namensraums oder durch Kompromittierung des Maintainer-Accounts. Der Schadcode wird über die normale Update-Infrastruktur verteilt. Ihre Systeme laden ihn automatisch herunter.

5. Maintainer-Überlastung Ein Maintainer ist nicht böswillig, aber überfordert. Sicherheitsmeldungen bleiben wochenlang unbearbeitet. Patches werden mit Verzögerung geprüft. Die Qualität sinkt. Das Projekt wird zum Risiko, obwohl es offiziell noch "aktiv" ist.

Nicht nur Runtime: Entwicklungsabhängigkeiten gehören dazu #

Wenn von "Lieferkette" die Rede ist, denken viele nur an Komponenten, die im fertigen Produkt landen - die Runtime-Abhängigkeiten. Aber Ihre Lieferkette umfasst auch alles, was Sie zum Bauen, Testen und Ausliefern Ihrer Software verwenden: Compiler, Build-Tools, Test-Frameworks, CI/CD-Pipelines, Paketmanager und deren Plugins.

Warum das wichtig ist: Ein kompromittiertes Build-Tool kann Schadcode in Ihr Endprodukt einschleusen, ohne dass eine einzige Zeile Ihres Quellcodes oder Ihrer Runtime-Abhängigkeiten verändert wird. Der XZ-Utils-Angriff 2024 hat genau das gezeigt - der Schadcode wurde über den Build-Prozess eingeschleust.

Die Gesetze machen hier keinen Unterschied: NIS2 Art. 21 Abs. 2 lit. e verlangt Sicherheitsmaßnahmen bei Entwicklung und Wartung. DORA Art. 25 Abs. 1 fordert Open-Source-Analysen als Pflichttest. Der CRA Art. 13 Abs. 5 verlangt Sorgfalt bei der Integration von FOSS-Komponenten - nicht nur bei deren Auslieferung.

Was fordern die Gesetze? #

Die EU-Gesetzgebung behandelt Open-Source-Abhängigkeiten als Teil Ihrer Lieferkette - Runtime- und Entwicklungsabhängigkeiten gleichermaßen:

• DORA Art. 28 Abs. 1: IKT-Drittparteienrisiko als integraler Bestandteil - Finanzunternehmen bleiben jederzeit voll verantwortlich
• DORA Art. 28 Abs. 4: Due Diligence vor Vertragsschluss mit IKT-Drittdienstleistern - auch bei OSS-Integration
• DORA Art. 28 Abs. 8: Ausstiegsstrategien für IKT-Drittdienstleister - auch für OSS-Abhängigkeiten relevant
• DORA Art. 25 Abs. 1: Open-Source-Analysen als Pflichttest - umfasst alle eingesetzten Komponenten
• NIS2 Art. 21 Abs. 2 lit. d: Sicherheit der Lieferkette als Pflichtmaßnahme
• NIS2 Art. 21 Abs. 2 lit. e: Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung, einschließlich Schwachstellenmanagement
• NIS2 Art. 21 Abs. 3: Bewertung der Schwachstellen und Entwicklungsprozesse unmittelbarer Anbieter
• CRA Art. 13 Abs. 5: Sorgfaltspflicht bei der Integration von FOSS-Komponenten
• CRA Art. 13 Abs. 25: Die EU kann eine unionsweite Abhängigkeitsbewertung für FOSS-Komponenten beschließen

Veraltete Abhängigkeiten: Das Problem kaskadiert #

Das Risiko veralteter Abhängigkeiten beginnt nicht bei Ihnen. 90 % der untersuchten kommerziellen Codebasen enthalten Open-Source-Komponenten, die mehr als vier Jahre veraltet sind. 71,6 % der Abhängigkeiten in Open-Source-Projekten selbst sind veraltet. Das bedeutet: Wenn ein kommerzieller Anbieter veraltete Open-Source-Software einsetzt, bezieht er über die Lieferkette noch weitere veraltete Software - das Risiko kaskadiert durch jede Ebene. 95 % aller Schwachstellen stecken in genau diesen transitiven Abhängigkeiten, die niemand bewusst ausgewählt hat. Mehr dazu unter Warum Ihre SBOM verrottet.

Kein Vertrag, kein SLA #

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 %. Für die Masse der Abhängigkeiten, die Ihre Software mitbringt, gibt es keinen Anbieter, keinen Vertrag und keinen Eskalationsweg. Mehr dazu unter Open Source hat keinen Vertragspartner.

Was bedeutet das für Sie? #

Ihre Open-Source-Lieferkette ist kein abstraktes Konzept. Sie besteht aus konkreten Projekten, konkreten Maintainern und konkreten Risiken. Die Gesetze verlangen, dass Sie diese Risiken kennen, bewerten und managen. "Wir verwenden nur etablierte Projekte" reicht als Strategie nicht aus - denn auch etablierte Projekte verwaisen, und auch populäre Projekte werden angegriffen.

Weiterlesen #

• Wer pflegt eigentlich Open Source?
• Open Source hat keinen Vertragspartner
• Was ist eine SBOM und warum reicht sie nicht?

Sie möchten die Risiken in Ihrer Open-Source-Lieferkette verstehen? OTTRIA analysiert Ihre SBOM und zeigt Ihnen, wo Sie handeln müssen. Fordern Sie eine Erstanalyse an.