deenx-default

Falsche Sicherheit: Warum Scanner und Dienstleister-Versprechen nicht reichen

Viele Unternehmen glauben, ihre Open-Source-Lieferkette im Griff zu haben - weil sie ein Tool einsetzen, eine SBOM erstellt haben oder sich auf die Zusage ihres Dienstleisters verlassen. Diese Annahme ist nachvollziehbar - und falsch. Die regulatorischen Anforderungen gehen deutlich weiter. Hier ist, warum.

SCA-Tools finden nur gemeldete Lücken - nicht alle bekannten #

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 stellen nicht auf gemeldete Schwachstellen ab. Der CRA fordert in Anhang I Teil I Nr. 2a die Freiheit von "bekannten ausnutzbaren Schwachstellen" - und bei der Integration fremder Komponenten verlangt Art. 13 Abs. 5 die "gebotene Sorgfalt", damit diese Komponenten die Cybersicherheit des Produkts nicht beeinträchtigen. NIS2 fordert in Art. 21 Maßnahmen unter Berücksichtigung des "Stands der Technik". Kein Gesetz begrenzt den Maßstab auf das, was in Datenbanken steht.

Wer sich auf SCA-Tools allein verlässt, deckt den gemeldeten Anteil ab - und übersieht die bekannte Mehrheit.

Silent Fixes: Die bekannte, aber nicht gemeldete 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.

SBOMs verrotten #

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 verlangt vom Hersteller, Schwachstellen und Komponenten fortlaufend zu ermitteln und zu dokumentieren; die SBOM ist dafür das vorgesehene Werkzeug (Anhang I Teil II Nr. 1). Eine eingefrorene SBOM erfüllt keine dieser Anforderungen.

Lieferkettensicherheit ist keine einmalige Inventur. Sie ist eine permanente Tätigkeit.

Decision Debt: Die stille Verschuldung #

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.

"Stand der Technik" ist nicht statisch #

DORA verlangt einen IKT-Risikomanagementrahmen mit Strategien, Leitlinien, Verfahren und Werkzeugen zum Schutz der IKT-Assets (Art. 6 Abs. 2). NIS2 fordert Maßnahmen "unter Berücksichtigung des Stands der Technik" (Art. 21 Abs. 1). Die DSGVO verlangt in Art. 25 Abs. 1 und Art. 32 Abs. 1 ebenfalls, den "Stand der Technik" zu berücksichtigen - 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 zeigen, wie breit die Aufsicht prüft: Advanced Computer Software Group (ICO, 2025, 3,1 Mio. GBP - Zugang über ein Kundenkonto ohne Mehrfaktor-Anmeldung, Rechteausweitung wahrscheinlich über die seit rund zwei Jahren bekannte Zerologon-Lücke, gerügt wurden "ad hoc patch management" und unzureichendes Schwachstellenscanning), Dedalus Biologie (CNIL, 2022, 1,5 Mio. Euro - Gesundheitsdaten von rund 500.000 Menschen unzureichend geschützt, Art. 28, 29 und 32), British Airways (ICO, 2020, 20 Mio. GBP - Eindringen über einen Fernzugang, danach Manipulation einer JavaScript-Datei), Deutsche Wohnen (Systeme nicht rechtzeitig für die fristgerechte Löschung angepasst; das Landgericht Berlin I setzte die Geldbuße 2026 auf 900.000 Euro fest) und Morele.net (UODO, 2024, über 3,8 Mio. PLN - fehlende Zwei-Faktor-Anmeldung und unzureichende Überwachung).

Fehlendes Patch- und Schwachstellenmanagement ist in diesen Fällen ein wiederkehrender, aber nicht der einzige Vorwurf. Es ist zugleich der Teil, den Sie systematisch schließen können - und Art. 83 Abs. 2 lit. d DSGVO lässt die nach Art. 25 und 32 getroffenen Maßnahmen ausdrücklich in die Bußgeldbemessung einfließen. Ausführlich mit Quellen: Die DSGVO und Open-Source-Governance.

Für schwere Bugs gibt es keine Datenbank #

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 verlangt in Art. 10 Abs. 1, anomale Aktivitäten "darunter auch Probleme bei der Leistung von IKT-Netzwerken" umgehend zu erkennen und "potenzielle einzelne wesentliche Schwachstellen" zu ermitteln. Die Pflicht endet also nicht bei dem, was als Sicherheitslücke gemeldet ist.

Whole-of-IT: Die Verantwortung endet nicht beim eigenen Code #

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.

Fünf Jahre Update-Garantie — das Versprechen, das niemand halten kann #

Der CRA verlangt in Art. 13 Abs. 8 einen Unterstützungszeitraum, der die voraussichtliche Nutzungsdauer des Produkts abbildet - grundsätzlich mindestens fünf Jahre, kürzer nur bei erwartbar kürzerer Nutzung. Ob Sie diese Pflicht als Hersteller trifft, hängt davon ab, wer das Produkt unter eigenem Namen oder eigener Marke vermarktet (Art. 3 Nr. 13): Bei Auftragsentwicklung kann das Ihr Kunde sein. Unabhängig von der Rolle geben Dienstleister und Agenturen ihren Kunden vertraglich entsprechende Update-Zusagen. Viele davon sind gut gemeint, aber nicht haltbar.

Das Problem liegt nicht beim Dienstleister selbst, sondern bei dem, was er nicht kontrolliert. Eine typische Unternehmensanwendung enthält hunderte Open-Source-Komponenten. Jede einzelne davon kann innerhalb von fünf Jahren verwaisen — weil der Maintainer aufhört, das Interesse verliert oder keine Zeit mehr hat. Projekte werden ohne Vorwarnung gelöscht oder wechseln ihre Lizenz auf Bedingungen, die eine weitere Nutzung unmöglich machen. Wenn das passiert, gibt es niemanden mehr, der Sicherheitsupdates liefert — oder die rechtliche Grundlage für die Nutzung entfällt vollständig. Der Dienstleister hat eine Garantie abgegeben, die er nicht einlösen kann, weil die Quelle versiegt, verschwunden oder rechtlich unzugänglich geworden ist.

Erschwerend kommt hinzu: Viele Dienstleister wissen gar nicht, welche Open-Source-Komponenten in ihrer Software stecken. Ohne eine aktuelle SBOM fehlt ihnen der Überblick über ihre eigenen Abhängigkeiten. Sie können nicht beurteilen, welche Projekte gepflegt werden und welche nicht — geschweige denn, ob in fünf Jahren noch jemand Sicherheitsupdates für diese Projekte bereitstellt. Eine SBOM, die täglich an Wert verliert, ist keine Grundlage für eine Fünfjahresgarantie.

Die Konsequenz: Wer fünf Jahre Sicherheitsupdates garantiert, ohne die Open-Source-Projekte in seiner Lieferkette aktiv zu unterstützen, gibt ein Versprechen ab, das er strukturell nicht halten kann. Aktive Unterstützung bedeutet: Verwaisungsrisiken überwachen, Löschungen und Lizenzwechsel frühzeitig erkennen, bei Bedarf selbst Patches erstellen, Forks pflegen, Maintainer-Koordination übernehmen. Ohne diese operative Eingriffsfähigkeit ist die Garantie ein Blatt Papier.

"DORA ist umgesetzt" — die gefährlichste Aussage Ihres Dienstleisters #

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. 24 DORA verlangt ein Testprogramm, das regelmäßig durchlaufen wird — keine einmalige Prüfung; Art. 25 Abs. 1 benennt Open-Source-Analysen darin ausdrücklich als Testmethode. 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, damit diese die Sicherheit des Produkts nicht beeinträchtigen. Findet ein Hersteller dort eine Schwachstelle, muss er sie nach Art. 13 Abs. 6 an die betreuende Stelle melden und eine selbst entwickelte Korrektur gegebenenfalls teilen. 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 gemeldete Sicherheitslücken. Er nennt neben den "potenziellen einzelnen wesentlichen Schwachstellen" ausdrücklich auch "Probleme bei der Leistung von IKT-Netzwerken" — in der Praxis reden wir damit über betriebsgefährdende Fehler: 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?

Open Source ist öffentlich — für Auditoren und Angreifer gleichermaßen #

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.

"Unsere SBOM ist vertraulich" — das Argument, das keines ist #

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.

Die Illusion der Delegation #

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.

Verbände und Nicht-Techniker verstehen die Implikationen nicht #

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.

Das Gesamtbild #

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.

Was OTTRIA anders macht #

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.

Was Sie konkret erhalten

OTTRIA im Marktvergleich

Sprechen Sie mit uns über Ihre Lieferkette