Seit das Schwachstellenmanagement Teil der Cyberabwehr geworden ist, wurde es üblicherweise an jährlichen Penetrationstests, vierteljährlichen Scans und regelmäßigen Programmen zur Behebung gemessen.
Kurz gesagt: DORA hat nicht verändert, was Finanzunternehmen im Umgang mit Schwachstellen tun müssen – sondern wie konsequent, wie umfassend und wie nachweisbar sie es tun müssen.
Für die meisten Sicherheitsteams ist das kein bloßes Update ihres bisherigen Vorgehens, sondern ein grundlegend anderes Betriebsmodell.
Entsprechend steigt der Bedarf an einer Kombination aus kontinuierlicher Überwachung und risikobasierter Priorisierung. Und es ist an der Zeit, sich mit Shift-Left-Testing zu befassen – also damit, Testaktivitäten früher im Entwicklungszyklus durchzuführen. So lassen sich Schwachstellen leichter aufspüren und ihre Auswirkungen wie auch die Behebungskosten in späteren Phasen verringern.
Kontinuierliche Überwachung löst punktuelle Sicherheitsprüfungen ab
Wer Probleme fortlaufend überwacht und Veränderungen in Echtzeit erkennt, ist nicht nur besser geschützt, sondern auch besser vorbereitet, wenn der Prüfer vor der Tür steht.
Nehmen wir Artikel 9 der DORA. Er verpflichtet Finanzunternehmen dazu, über periodische Sicherheitsbewertungen hinauszugehen und ihre IKT-Systeme stattdessen laufend zu überwachen, zu verwalten und zu schützen. Dazu gehört die Umsetzung von Sicherheitsrichtlinien, -verfahren, -werkzeugen und -kontrollen, die Resilienz, Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit der Systeme und Daten gewährleisten – insbesondere dort, wo kritische Geschäftsfunktionen unterstützt werden.
Im Kern verlagert Artikel 9 die IKT-Sicherheit von einer reaktiven, zeitpunktbezogenen Tätigkeit hin zu einer dauerhaften operativen Disziplin, die Cyberrisiken senken und die operationale Resilienz jederzeit aufrechterhalten soll.
Die in der DORA verankerte Anforderung an kontinuierliche Überwachung und Kontrolle bedeutet, dass Unternehmen durchgehend Transparenz über ihre gesamte IKT-Umgebung wahren müssen. Nur so können sie Schwachstellen, Bedrohungen und operative Risiken in Echtzeit erkennen, bewerten und darauf reagieren – statt sich auf periodische Bewertungen oder Momentaufnahmen zu verlassen.
Offen gesagt reichen jährliche Scans und vierteljährliche Reviews nicht mehr aus: DORA-Compliance verlangt einen Wechsel des Betriebsmodells.
Ein Anwender konnte beispielsweise die Scan-Ergebnisse von Mondoo nutzen, um fortlaufend Nachweise zu liefern, statisches Benchmarking abzulösen und grundlegende Sicherheitsanforderungen als Baseline zu etablieren.
Shift-Left-Sicherheit ist jetzt eine regulatorische Anforderung
Dieser Trend zu einem effizienteren Ansatz bei Tests und Projektmanagement – bei dem Code und Anwendungen früher geprüft und mögliche Schwachstellen eher erkannt werden – ist nicht neu, hat sich aber längst nicht überall durchgesetzt.
Das Prinzip „früh und häufig testen“ gibt es bereits seit Anfang des Jahrhunderts. Der State of DevOps Report 2016 zeigte, dass leistungsstarke Teams rund 50 Prozent weniger Zeit für die Behebung von Sicherheitsproblemen aufwenden als andere. Der Druck, Projekte schnell auszuliefern und generell zügiger zu arbeiten, hat jedoch die Wahrscheinlichkeit erhöht, dass Schwachstellen in Produktivumgebungen gelangen.
Was hat das nun mit der DORA-Compliance zu tun? Laut PwC UK baut DORA auf bestehenden branchenspezifischen Vorgaben auf und definiert Anforderungen an das IKT-Risikomanagement, an Fähigkeiten zum Resilienztest (einschließlich bedrohungsorientierter Penetrationstests) sowie an das Risikomanagement gegenüber Dritten – und stellt so eine durchgängige Leistungserbringung über die gesamte Wertschöpfungskette hinweg sicher.
Auch wenn es in der Verordnung nicht ausdrücklich steht, wird Shift-Left-Testing damit implizit gefördert – denn Vorbeugung wird der Erkennung vorgezogen. Entwicklungsteams werden so Teil des Compliance-Prozesses. Schwachstellen, die erst nach der Veröffentlichung entdeckt werden, können nämlich zum regulatorischen Risiko werden, wenn ein Unternehmen keine angemessenen Testverfahren einhält.
Das Backlog-Problem: Warum mehr Funde mehr Risiko bedeuten
Dafür, dass sich Shift-Left-Testing bislang nicht stärker durchgesetzt hat, gibt es mehrere wahrscheinliche Gründe:
- Es verlangsamt den Entwicklungsprozess.
- Es entsteht ein Backlog an Schwachstellen, die abgearbeitet werden müssen.
- Es erfordert eine Analyse von Ausnutzbarkeit und Asset-Kontext.
Denn gefundene Schwachstellen müssen auch behoben werden. Versetzen Sie sich in die Perspektive der Aufsicht: „Wie viele Schwachstellen haben Sie identifiziert?“ und „Wie haben Sie priorisiert und behoben?“ Ein unkontrollierter Backlog kann zum Compliance-Problem werden, denn jemand muss die Verantwortung dafür übernehmen, das Gefundene zu beheben.
Werfen wir einen Blick auf Artikel 10 der DORA zum Schwachstellen- und Patch-Management. Er hält Unternehmen, die Compliance anstreben, unter anderem dazu an,
- Verfahren für die verantwortungsvolle Offenlegung von Schwachstellen gegenüber Kunden, Geschäftspartnern und der Öffentlichkeit einzurichten,
- die Bereitstellung von Patches und anderen Gegenmaßnahmen zur Behebung erkannter Schwachstellen zu priorisieren,
- die Behebung von Schwachstellen zu überwachen und zu verifizieren,
- erkannte Schwachstellen an IKT-Systemen zu dokumentieren und deren Behebung nachzuverfolgen.
Das Scannen von Code, Software und Anwendungen kann zusätzliche Funde hervorbringen – was wiederum Aufwand für Patching und verantwortungsvolle Offenlegung nach sich zieht. Zwar spart die frühzeitige Behebung von Problemen Zeit und führt zu sichereren Ergebnissen, doch sollten Unternehmen genau abwägen, wie viel zusätzliches Risiko und wie viel Mehraufwand dadurch entstehen.
Beziehen Sie das in Ihr Schwachstellenmanagement und Ihre Prozesse ein und prüfen Sie, ob Sie die Kapazität haben, mit dem umzugehen, was Sie finden – gerade dann, wenn Geschwindigkeit in Ihrem Entwicklungszyklus entscheidend ist. Es kann sich lohnen, eine zusätzliche Person oder ein Team damit zu betrauen, Schwachstellen direkt bei ihrer Entdeckung zu bearbeiten, um Behebungs- und Meldezeiten möglichst gering zu halten.
Das Lieferkettenrisiko ist im Compliance-Perimeter angekommen
Neben Ihren Prozessen zur Schwachstellenerkennung bleibt auch Ihre Lieferkette ein zentraler Bestandteil der DORA-Compliance.
Eines der Ziele von DORA ist es, die digitale operationale Resilienz im Finanzsektor zu stärken, indem Risiken innerhalb der IKT-Lieferkette adressiert werden. Insbesondere betont Artikel 29 die Notwendigkeit, umfassende Transparenz über die Lieferkette zu wahren – durch Identifizierung, Klassifizierung und fortlaufende Überwachung aller IKT-Dienstleister, die kritische oder wichtige Funktionen unterstützen.
Dazu zählen auch Schwachstellen, die über die Lieferkette eingebracht werden, sowie das Ausmaß, in dem Ihr Unternehmen von Open-Source-Software abhängt – und Anbieter, die ihrerseits auf Drittdienste angewiesen sind. Wenn ein kritischer Dienst plötzlich ausfällt: Wie bedienen Sie dann weiterhin Ihre Kundinnen und Kunden? Sie bleiben verantwortlich, unabhängig davon, welche Dienste Sie nutzen – und das sollte sich bei der Auswahl von Lieferanten in Ihrem Risikoprofil widerspiegeln.
Selbst wenn Sie eine anfällige Komponente nicht unmittelbar kontrollieren, bleiben Sie für die Meldung und Behebung damit verbundener Schwachstellen verantwortlich. So dehnt DORA das Schwachstellenmanagement weit über selbst entwickelte Systeme hinaus aus – denn viele Firmen haben ihre Programme bislang nicht auf Drittabhängigkeiten ausgeweitet.
Ein Beispiel liefert die Kompromittierung von Trivy im März 2026. Dabei nahm TeamPCP den Schwachstellen-Scanner Trivy von Aqua Security ins Visier – samt seiner GitHub Actions und Docker-Images. Mithilfe gestohlener Zugangsdaten, die bei einem früheren Vorfall erbeutet worden waren, konnte der Angreifer eine Fehlkonfiguration in Trivys GitHub-Actions-Umgebung ausnutzen, ein privilegiertes Zugriffstoken extrahieren und sich in der Repository-Automatisierung und den Release-Prozessen festsetzen.
Trivy ist in Tausenden von CI/CD-Pipelines eingebettet. Der Vorfall betraf Millionen von Entwicklern und Hunderttausende CI/CD-Pipelines – mit potenziell langfristiger Gefährdung durch den Diebstahl von Zugangsdaten und persistente Schadsoftware. Aqua Security sah sich zu einer umfassenden Untersuchung gezwungen und räumte ein, seine Lieferkette nicht ausreichend geschützt zu haben. Der Angriff lief mehrere Stunden, bevor er entdeckt und gestoppt wurde.
Eine spätere Untersuchung zeigte, dass die Rotation der Zugangsdaten nicht vollständig war, sodass der Bedrohungsakteur über weiterhin gültige Anmeldedaten Restzugriff behielt. Da die Angreifer bestehende Versions-Tags von trivy-action veränderten, schleusten sie Schadcode in Workflows ein, die Organisationen bereits ausführten.
Weil viele CI/CD-Pipelines auf Versions-Tags setzen, liefen diese Pipelines einfach weiter – ohne jeden Hinweis darauf, dass sich der zugrunde liegende Code verändert hatte.
Der Vorfall ist eine eindringliche Erinnerung daran, dass das Lieferkettenrisiko nicht bei den Software-Abhängigkeiten endet, sondern bis in die Sicherheitswerkzeuge selbst hineinreicht.
Auch die Aufsichtsbehörden haben das registriert: Im Januar 2026 ging die BaFin noch einen Schritt weiter und ordnete KI-Systeme dem IKT-Rahmenwerk der DORA zu. Der Einsatz von KI sei mit „größeren Risiken“ verbunden, und Finanzunternehmen sollten angemessene Governance- und Organisationsstrukturen festlegen, um die aus KI-Systemen entstehenden IKT-Risiken zu begrenzen.
Das umfasst LLMs, Copiloten und agentische Systeme, die allesamt zunehmend regelmäßig bewertet werden müssen – ebenso wie die Frage, welche Folgen ihr Ausfall für den Geschäftsbetrieb hätte.
Audit-Trails: Der Unterschied zwischen Compliance und Nachweis
Um DORA-Compliance zu erreichen und aufrechtzuerhalten, müssen Unternehmen eine fortlaufende, maschinenlesbare Aufzeichnung ihrer Aktivitäten führen. Nur so können sie gegenüber den Aufsichtsbehörden belegen, was wann gefunden wurde und welche Maßnahmen ergriffen wurden. Etablieren Sie eine Kultur, in der Nachweise proaktiv zusammengetragen werden – DORA verlangt das, und es spart erheblich Zeit, wenn der Prüfer anklopft.
Auch Compliance-Nachweise sollten kontinuierlich entstehen und nicht in den Tagen vor einem Audit hastig zusammengestellt werden. DORA verlangt, dass Unternehmen belegen, was geschehen ist – und nicht bloß behaupten, dass es geschehen ist.
Fazit: Schwachstellenmanagement ist zur Resilienzfunktion geworden
Letztlich hat DORA nicht verändert, was Unternehmen im Umgang mit Schwachstellen tun müssen – sondern wie konsequent, wie umfassend und wie überzeugend sie es nachweisen müssen.
Die Unternehmen, die unter DORA erfolgreich sind, finden nicht unbedingt weniger Schwachstellen; sie bauen Prozesse auf, die kontinuierlich Kontrolle, Resilienz und Verantwortlichkeit belegen. Schwachstellenmanagement bedeutet längst nicht mehr nur, Probleme zu finden und zu beheben. Es geht darum, einen Audit-Trail zu pflegen, eine Lieferkette zu steuern und zu verstehen, was im eigenen Unternehmen geschieht – und wie sich das auf die operationale Resilienz auswirkt.
