Viele Unternehmen glauben, mit einem CVE-Scanner, einer SBOM und der Zusage ihres Dienstleisters regulatorisch auf der sicheren Seite zu sein. Diese Annahme ist nachvollziehbar - und falsch. Hier ist, warum.
SCA-Tools (Software Composition Analysis) scannen Ihre Komponenten gegen mehrere Datenbanken - CVE, GitHub Security Advisories, NVD, Paketmanager-Warnungen und weitere. Das ist deutlich mehr als ein reiner CVE-Scan. Aber alle diese Datenbanken haben dasselbe strukturelle Problem: Sie enthalten nur Schwachstellen, die jemand aktiv gemeldet hat.
Der Unterschied ist entscheidend:
Die EU-Gesetze fordern nicht die Freiheit von gemeldeten Schwachstellen. Der CRA fordert in Anhang I Teil I Nr. 2a die Freiheit von "bekannten ausnutzbaren Schwachstellen" - und die Sorgfaltspflicht bei FOSS-Integration (Art. 13 Abs. 5) verlangt die Prüfung gegen alle bekannten Schwachstellen. NIS2 fordert in Art. 21 Maßnahmen nach dem "Stand der Technik". Kein Gesetz beschränkt sich auf das, was in Datenbanken steht.
Wer sich auf SCA-Tools allein verlässt, deckt den gemeldeten Anteil ab - und übersieht die bekannte Mehrheit.
Auf jede gemeldete Schwachstelle kommen vier bis elf sicherheitsrelevante Korrekturen, die ohne Eintrag in irgendeiner Datenbank in den Code einfließen. Maintainer beheben Probleme oft stillschweigend (Silent Fixes) - in einem regulären Commit, ohne Sicherheitshinweis, ohne Advisory, ohne CVE-Nummer.
Diese Silent Fixes sind keine Randerscheinung. Sie sind die Mehrheit aller Sicherheitskorrekturen. Das Problem war bekannt - dem Maintainer, der es behoben hat. Aber es wurde nie gemeldet - und ist damit für jedes SCA-Tool der Welt unsichtbar.
Für Ihr Unternehmen bedeutet das: Zwischen dem Moment, in dem ein Maintainer ein Sicherheitsproblem stillschweigend behebt, und dem Moment, in dem Sie das Update einspielen, sind Sie verwundbar - ohne es zu wissen. OTTRIA erkennt Silent Fixes durch aktive Code-Analyse und Beteiligung an den Projekten.
Eine SBOM ist ein Snapshot. Am Tag der Erstellung zeigt sie korrekt, welche Komponenten in welcher Version in Ihrem Produkt stecken. Einen Tag später beginnt sie zu veralten.
Projekte veröffentlichen Updates. Neue transitive Abhängigkeiten kommen hinzu. Maintainer wechseln. Lizenzen ändern sich. Projekte werden archiviert oder gelöscht. Nichts davon bildet Ihre SBOM automatisch ab.
DORA fordert in Art. 8 Abs. 6 die regelmäßige Aktualisierung des IKT-Asset-Inventars bei jeder wesentlichen Änderung. NIS2 setzt über die Lieferkettenpflicht (Art. 21 Abs. 2 lit. d) aktuelle Kenntnis aller Komponenten voraus. Der CRA fordert die SBOM als kontinuierlichen Prozess. Eine statische SBOM erfüllt keine dieser Anforderungen.
Lieferkettensicherheit ist keine einmalige Inventur. Sie ist eine permanente Tätigkeit.
In vielen Open-Source-Projekten gibt es Architekturentscheidungen, die seit Jahren aufgeschoben werden. Veraltete APIs, die niemand ablöst. Sicherheitsrelevante Refactorings, für die niemand Zeit hat. Technische Schulden, die von Commit zu Commit wachsen.
Diese Probleme tauchen in keiner Schwachstellendatenbank auf. Es gibt keine CVE für eine schlechte Architekturentscheidung, keine Warnung für eine veraltete Kryptografie-Bibliothek, die technisch noch funktioniert, aber nicht mehr dem Stand der Technik entspricht.
Für Ihr Unternehmen ist Decision Debt gefährlicher als ein bekannter Bug - weil Sie nicht einmal wissen, dass das Risiko existiert. Nur wer aktiv im Code arbeitet und die Projekte von innen kennt, erkennt diese Risiken.
DORA fordert einen Risikomanagementrahmen nach Maßgabe "einschlägiger internationaler Normen" (Art. 6 Abs. 2). NIS2 fordert Maßnahmen nach dem "Stand der Technik" (Art. 21 Abs. 1). Die DSGVO verlangt in Art. 25 Abs. 1 und Art. 32 Abs. 1 ebenfalls den "Stand der Technik" - und zusätzlich, dass Integrität, Verfügbarkeit und Belastbarkeit "auf Dauer" sichergestellt werden. Alle drei Formulierungen sind bewusst offen gehalten.
Was heute dem Stand der Technik entspricht, kann morgen unzureichend sein. Neue Angriffsmethoden, neue Erkenntnisse, neue Standards wie die ISO/IEC 18974 verschieben kontinuierlich, was als "angemessen" gilt.
Ein CVE-Scanner war vor fünf Jahren Stand der Technik. Heute ist er notwendig, aber nicht hinreichend. Wer vor einer Aufsichtsbehörde argumentieren muss, warum seine Maßnahmen angemessen sind, braucht mehr.
Die dokumentierten DSGVO-Bußgelder zeichnen ein klares Bild: Veraltete oder ungepflegte Software ist der häufigste einzelne Auslöser. Advanced Computer Software Group (ICO, 2025, 3,1 Mio. GBP, ungepatchte kritische Schwachstelle CVSS 10.0 seit zwei Jahren, "ad hoc patch management", erstes Processor-Bußgeld unter UK GDPR), Dedalus Biologie (CNIL, 2022, 1,5 Mio. Euro, rund 500.000 Gesundheitsdatensätze, Art. 28/29/32), British Airways (20 Mio. GBP, manipulierte JavaScript-Bibliothek), Deutsche Wohnen (14,5 Mio. Euro, veraltete Archivierungssoftware), Morele.net (2,8 Mio. PLN, ungepatchte Schwachstelle) - überall dasselbe Muster: Die Schwachstelle war bekannt, der Fix war verfügbar, niemand hatte den Überblick. Genau dafür ist Open-Source-Governance da - und genau diese Lücke adressiert Art. 83 Abs. 2 lit. d DSGVO, der dokumentierte Maßnahmen nach Art. 25 und 32 ausdrücklich bußgeldmindernd berücksichtigt.
CVE-Datenbanken erfassen Sicherheitslücken. Aber was ist mit Fehlern, die den Geschäftsbetrieb gefährden, ohne im klassischen Sinne Sicherheitslücken zu sein? Abstürze unter Last, Datenverlust bei bestimmten Eingaben, Inkompatibilitäten nach Updates - für diese Kategorie von Problemen existiert keine strukturierte Datenbank und kein Scanner.
DORA fordert in Art. 10 Abs. 1 die Ermittlung "potenzieller einzelner wesentlicher Schwachstellen". Das schließt Betriebsrisiken ausdrücklich ein.
DORA und NIS2 verfolgen einen Whole-of-IT-Ansatz. Die Pflichten zur Risikokontrolle umfassen nicht nur Ihre eigene Software, sondern den gesamten Stack - einschließlich aller Open-Source-Komponenten, deren transitiver Abhängigkeiten und der Dienste Ihrer IKT-Drittdienstleister (DORA Art. 28, NIS2 Art. 21 Abs. 2 lit. d, CRA Art. 13 Abs. 5).
Viele Unternehmen unterschätzen den Umfang dieser Pflicht. Die SBOM zeigt 800 Projekte - aber die tatsächliche Angriffsfläche umfasst tausende transitiver Abhängigkeiten, die kein Mensch manuell überblicken kann.
Zentrale IT-Dienstleister im Finanzsektor verkünden ihren Kunden: "DORA ist umgesetzt." Diese Aussage klingt beruhigend. Sie ist aber bestenfalls irreführend — denn DORA ist kein Projekt mit einem Abschlussdatum. DORA ist ein Regime permanenter Pflichten.
Art. 25 Abs. 1 DORA schreibt Open-Source-Analysen als laufende Testmethode vor — nicht als einmalige Prüfung. Art. 28 Abs. 1-2 verlangt das kontinuierliche Management aller IKT-Drittparteienrisiken. Art. 9 Abs. 4f fordert dokumentierte Richtlinien für Patches und Updates. Art. 8 Abs. 6 verlangt die Aktualisierung des IKT-Asset-Inventars bei jeder wesentlichen Änderung. Keine dieser Pflichten ist jemals "umgesetzt" im Sinne von "erledigt".
Was tun diese Dienstleister tatsächlich? Im besten Fall pflegen sie eine SBOM und betreiben CVE-Scanning. Das ist Layer 1: Sichtbarkeit. Aber DORA fordert mehr. Art. 13 Abs. 5 CRA verlangt von Herstellern die "gebotene Sorgfalt" bei der Integration von FOSS-Komponenten — einschließlich der Hinwirkung auf sichere Entwicklung. Art. 10 Abs. 1 DORA fordert die Ermittlung "potenzieller einzelner wesentlicher Schwachstellen" — nicht nur der registrierten.
Besonders brisant: Art. 10 Abs. 1 DORA beschränkt sich nicht auf Sicherheitslücken. Er fordert die Ermittlung "potenzieller einzelner wesentlicher Schwachstellen" — das schließt betriebsgefährdende Fehler ausdrücklich ein. Abstürze unter Last, Datenverlust bei bestimmten Eingaben, Inkompatibilitäten nach Updates. Für diese Kategorie von Problemen existiert keine Datenbank wie CVE oder NVD. Es gibt kein standardisiertes Meldesystem, keinen Scanner, keine etablierte Lösung. Kein Dienstleister kann behaupten, diese Pflicht mit einem Standard-Tool "umgesetzt" zu haben — weil das Standard-Tool nicht existiert. OTTRIA hat hierfür einen eigenen Prozess entwickelt, der automatisiertes Scanning, KI-gestützte Commit-Analyse und manuelles Code-Review kombiniert. Aber auch dieser Prozess funktioniert nur, weil OTTRIA aktiv in den Projekten mitarbeitet — denn betriebsgefährdende Fehler erkennt man nicht von außen.
Wer eine SBOM pflegt, hat ein Inventar erstellt. Wer CVEs scannt, hat eine Liste bekannter Meldungen. Aber wer erkennt die Fehler, die in keiner Datenbank stehen? Wer wirkt tatsächlich auf die sichere Entwicklung der Komponenten hin? Wer arbeitet aktiv in den Projekten mit?
Hier kommt die Eigenschaft ins Spiel, die im Namen steckt: das "Open" in Open Source bedeutet unter anderem öffentlich. Alles ist einsehbar. Für jeden.
Ein Auditor kann prüfen: "Ihr Dienstleister behauptet, er sichert Ihre Open-Source-Lieferkette ab. Zeigen Sie mir seine Commits in den Projekten Ihrer SBOM." Wenn die Antwort Schweigen ist, ist die Behauptung widerlegt — mit öffentlich zugänglichen Daten.
Und was ein Auditor sehen kann, kann ein Angreifer auch sehen. Die gleiche Transparenz, die Open Source stark macht, macht Untätigkeit sichtbar. Ein Angreifer, der ein Ziel im Finanzsektor sucht, kann die SBOMs der eingesetzten Produkte analysieren und gezielt Projekte angreifen, bei denen niemand aktiv mitarbeitet. Kein Commit seit Monaten, keine Reaktion auf Issues, keine Security-Advisories — das sind Einladungen.
Ein häufiger Einwand: Die SBOM sei ja nicht öffentlich, also könne niemand die Abhängigkeiten kennen. Das klingt nach Sicherheit durch Geheimhaltung. In der Praxis ist es eine Illusion.
SBOMs lassen sich in weiten Teilen rekonstruieren — ohne Zugang zum Quellcode, ohne Insiderwissen. Bereits grobe Kenntnisse reichen:
Ein Angreifer muss nicht die vollständige SBOM kennen. Grobe Kenntnis reicht, wenn sie die richtigen Komponenten trifft. Wer weiß, dass ein Finanzdienstleister Spring Boot in Version X einsetzt, braucht keine vollständige Stückliste — er braucht eine Schwachstelle in Spring Boot.
Geheimhaltung der SBOM ist kein Sicherheitskonzept. Sie ist ein Informationsvorsprung, der in der Praxis dünn bis nicht vorhanden ist. Die tatsächliche Sicherheit entsteht dadurch, dass jemand die Komponenten aktiv pflegt — nicht dadurch, dass niemand weiß, welche es sind.
DORA ist eindeutig: Finanzunternehmen bleiben jederzeit voll verantwortlich für die Einhaltung der IKT-Anforderungen, auch wenn sie Funktionen an Dritte auslagern (Art. 28 Abs. 1). Die Aussage "Unser Dienstleister hat DORA umgesetzt" entbindet von nichts. Sie verschiebt die operative Arbeit — aber nicht die Verantwortung, und nicht die Haftung.
Wenn ein Dienstleister Ihnen versichert, DORA sei "erledigt", fragen Sie konkret: In welchen Open-Source-Projekten meiner SBOM sind Sie aktiv? Welche Patches haben Sie beigetragen? Welche Schwachstellen haben Sie gemeldet? Welche Silent Fixes haben Sie erkannt? Die Antworten sind öffentlich überprüfbar.
OTTRIA kann diese Fragen beantworten. Jeder Commit, jedes Review, jede Meldung ist öffentlich einsehbar — für Sie, für Ihren Auditor und für jede Aufsichtsbehörde.
Ein erheblicher Teil der DORA- und NIS2-Betroffenen hat kein tiefes technisches Verständnis für Open-Source-Ökosysteme. Branchenverbände geben Handlungsempfehlungen, die "SBOM erstellen" und "CVE-Scanner einsetzen" als ausreichend darstellen. Das ist verständlich - aber es entspricht nicht dem, was die Gesetze tatsächlich fordern.
Einiges ist zwar bereits Gesetz, aber noch nicht detailliert definiert. Die Konkretisierung durch Durchführungsrechtsakte und ENISA-Leitlinien läuft noch. Wer sich heute nur auf das Minimum vorbereitet, riskiert morgen nachbessern zu müssen.
Die einzelnen Lücken addieren sich:
Kein einzelnes dieser Probleme ist allein kritisch. Zusammen ergeben sie eine systematische Schwachstelle in Ihrer Governance - genau die Stelle, an der Auditoren ansetzen und Aufsichtsbehörden nachhaken.
OTTRIA verlässt sich nicht auf eine einzige Quelle. Wir kombinieren CVE-Monitoring mit aktiver Code-Analyse, Silent-Fix-Detection, Projekt-Gesundheitsbewertung und Beteiligung im Ökosystem. Nicht weil ein einzelnes Werkzeug schlecht ist, sondern weil kein einzelnes Werkzeug genug ist.
Das Ergebnis: ein vollständiges Bild Ihrer Open-Source-Lieferkette - nicht nur der registrierte Ausschnitt.