Was die Titanic mit SBOM, CVEs und dem Cyber Resilience Act zu tun hat
Die Titanic galt als „unsinkbar“, bis ein Eisberg das Gegenteil bewies. Was hat das mit moderner Softwareentwicklung zu tun? Mehr als man denkt. Auch heutige IT-Systeme sind komplexe Konstrukte aus zahllosen Komponenten, größtenteils aus Open-Source-Projekten. Und wie bei der Titanic können kleine, übersehene Schwachstellen fatale Folgen haben.
Die Parallele ist klar: Egal ob Sie die Titanic gebaut haben oder nur Passagier sind, wenn Ihr Schiff sinkt, sind alle betroffen. Genauso verhält es sich mit modernen Software-Lieferketten. Selbst Unternehmen, die keine eigene Software entwickeln, sind gefährdet: Wenn sie Anwendungen nutzen, die auf unsicheren Abhängigkeiten basieren, denen man jedoch blind vertraut.
Open-Source-Sicherheit: Fundament und Risiko zugleich
Open Source ist das Rückgrat moderner Software. Sie ermöglicht Innovation, senkt Kosten, bietet Transparenz und sichert den Fortbestand zentraler Komponenten. Doch mit den Vorteilen kommen Risiken:
Laut dem OSSRA-Report (Open Source Security and Risk Analysis) von 2024 enthalten 84 % aller Codebasen bekannte Schwachstellen. Davon sind 26 % weniger kritisch – doch 74 % sind High Risk – ein Anstieg um 54 % gegenüber dem Vorjahr.
Ein wesentlicher Treiber dieser Komplexität sind transitive Abhängigkeiten. Dabei handelt es sich um indirekte Bibliotheken, die nicht direkt vom Entwickler, sondern in direkten Abhängigkeiten eingebunden sind. Beispiel: Ihre Anwendung nutzt Framework A, wie etwa Flask, das wiederum Bibliothek B – wie etwa Werkzeug – benötigt. Diese „Abhängigkeit der Abhängigkeit“ oder auch transitive Abhängigkeit, ist für Entwickelnde oft nicht direkt ersichtlich. Genau das macht sie riskant.
Warum sind transitive Abhängigkeiten gefährlich?
- Verdeckte Sicherheitslücken: Schwachstellen in indirekten Bibliotheken bleiben häufig unentdeckt.
- Fehlende Transparenz: Ohne automatisierte Tools ist es nahezu unmöglich, alle Abhängigkeiten zu identifizieren.
- Compliance-Risiken: Jede zusätzliche Bibliothek bringt eigene Lizenzbedingungen mit.
- Wartungsprobleme: Veraltete Komponenten erhöhen die Angriffsfläche und können zu Instabilität führen.
Das Problem: Jede Abhängigkeit kann, bildlich gesprochen, zum Eisberg werden, der das Schiff zum Sinken bringt. Und die Zahl der Abhängigkeiten wächst rasant. Microservices, Container und Cloud-Technologien erhöhen die Komplexität zusätzlich. Wer hier den Überblick verliert, riskiert nicht nur Sicherheitslücken, sondern zudem Compliance-Verstöße.
Praxisbeispiel: Ein Blick auf eine typische Software Supply Chain
Die Entwicklung moderner Software folgt einer klaren Lieferkette – von der ersten Codezeile bis zur Auslieferung an den Kunden. Im Schnelldurchlauf stellt sich dies wie folgt dar:
- Entwicklung: Entwickler schreiben den Code und integrieren Funktionen.
- Source Control: Der Code wird in ein Tool eingecheckt, das Versionierung und Verwaltung übernimmt.
- Build-Prozess: Aus dem Code entsteht die ausführbare Software. Hier werden zahlreiche Bibliotheken und Abhängigkeiten eingebunden – oft auch Open-Source-Komponenten.
- Packaging & Release: Die fertige Anwendung wird verpackt und für den Rollout vorbereitet.
- Deployment: Am Ende erfolgt die Bereitstellung in der Zielumgebung, sei es On-Premises oder in der Cloud.
Diese Supply Chain ist das Fundament jeder Softwarebereitstellung – aber auch ein potenzieller Risikofaktor. Jede Stufe kann Schwachstellen enthalten, insbesondere durch externe Bibliotheken und transitive Abhängigkeiten, die oft tief in der Kette verborgen sind. Wer hier den Überblick verliert, öffnet Angreifern Tür und Tor.
Warum Software Supply Chain Security unverzichtbar ist
Die Software Supply Chain ist längst ein bevorzugtes Ziel für Cyberkriminelle. Jeder Schritt im Software-Lifecycle kann zur Angriffsfläche werden. Drei typische Angriffsmethoden lauten:
- Brand Jacking – Missbrauch bekannter Marken
Angreifer imitieren den Namen oder die Identität einer etablierten Softwaremarke, um Vertrauen auszunutzen. Nutzer glauben, ein legitimes Paket zu installieren – tatsächlich handelt es sich um eine manipulierte Version mit Schadcode, Hintertüren oder anderen Gefahren. So dringen Cyberkriminelle unbemerkt in die Supply Chain ein. - Typosquatting – kleine Tippfehler, große Wirkung
Ein Buchstabe reicht: Angreifer veröffentlichen Pakete mit Namen, die populären Bibliotheken täuschend ähnlich sind. Ein Tippfehler beim Installieren genügt und Schadcode gelangt in die Anwendung. Das Vertrauen in bekannte Paketnamen wird gezielt ausgenutzt. - Dependency Hijacking – Übernahme verwaister Pakete
Verlassene oder nicht mehr gepflegte Pakete sind ein leichtes Ziel. Cyberkriminelle übernehmen die Kontrolle, fügen bösartigen Code hinzu – und dieser wird automatisch in Builds eingebunden. Die Manipulation bleibt oft lange unentdeckt und kann zahlreiche Projekte gleichzeitig gefährden.
Cyber Resilience Act: SBOM, Compliance und Schwachstellenmanagement einfach erklärt
Die beschriebenen Angriffe zeigen, wie verwundbar die Lieferkette ist. Genau hier setzt der Cyber Resilience Act (CRA) an: Er verpflichtet alle Akteure der Software-Supply-Chain, Sicherheitsmaßnahmen umzusetzen und Transparenz zu schaffen. Gefordert sind unter anderem:
✔ Transparenz über eingesetzte Komponenten (SBOM – Software Bill of Materials)
✔ Schwachstellenmanagement und zeitnahe Behebung
✔ Sicherheitsupdates und Compliance-Prüfungen
✔ Meldung kritischer Schwachstellen an die European Union Agency for Cybersecurity (Europäische Agentur für Cybersicherheit) ENISA
Unabhängig davon, ob Sie Software entwickeln oder konsumieren – diese Anforderungen betreffen alle. SBOMs sind dabei wie Zutatenlisten für Software: Sie schaffen Transparenz und ermöglichen es, Schwachstellen schnell zu identifizieren.
Schutz vor CVEs und Supply-Chain-Angriffen: SCA, SAST und Shift-Left Security
Wie können Unternehmen sich schützen? Die Lösung liegt in proaktiven Maßnahmen:
- Software Composition Analysis (SCA): Transparenz über alle Abhängigkeiten, Erstellung von SBOMs, Schwachstellen-Scanning
- Static Application Security Testing (SAST): Frühe Erkennung von Code-Schwächen im Entwicklungsprozess
- Shift-Left Security: Sicherheit von Anfang an integrieren
- Runtime Security: Schutz vor Zero-Day-Angriffen in laufenden Systemen
Diese Tools helfen nicht nur bei der Erkennung, sondern auch bei der Priorisierung von Schwachstellen – entscheidend für schnelle Reaktionen. Wer hier investiert, reduziert Risiken und erfüllt gleichzeitig regulatorische Anforderungen.
Fazit: Was wir von der Titanic für Software Supply Chain Security lernen können
Die Titanic scheiterte nicht an einem einzigen Eisberg, sondern an einer Kette von übersehenen Details und fehlender Vorbereitung. In der IT ist es ähnlich: Ein einzelner Fehler in der Software-Lieferkette kann verheerende Folgen haben – besonders, wenn er unentdeckt bleibt.
Nur wer seine Lieferkette kennt, überwacht und absichert, kann Risiken minimieren. Transparenz ist dabei der Schlüssel: SBOMs schaffen die notwendige Übersicht, Schwachstellenmanagement sorgt für schnelle Reaktion, und kontinuierliche Sicherheitsprüfungen verhindern, dass kleine Lücken zu großen Katastrophen werden. Die Verantwortung dafür liegt auf zwei Ebenen: Während IT- und Security-Teams die technischen Werkzeuge operativ einsetzen, müssen Geschäftsführung und Management den strategischen Rahmen setzen – und verstehen, dass Supply Chain Security mit ihren Regularien längst zur Führungsaufgabe geworden ist.
Damit ist Software Supply Chain Security keine Kür, sondern eine Pflicht – nicht nur aus technischer Sicht, sondern auch regulatorisch. Mit dem Cyber Resilience Act und ähnlichen Vorgaben wird klar: Unternehmen müssen handeln, bevor der Eisberg in Sicht ist. Wer jetzt investiert, schützt nicht nur seine Systeme, sondern auch Vertrauen, Reputation und Geschäftskontinuität.
Transparenzhinweis: Dieser Beitrag wurde von Fachexperten erstellt. KI‑Tools wurden ausschließlich zur Rechercheunterstützung und sprachlichen Optimierung verwendet