Was DORA für den Einsatz von Open Source Software bedeutet

Open Source Software (OSS) ist fester Bestandteil der IT‑Landschaft – von Finanzunternehmen über Frameworks und Bibliotheken in eigener Softwareentwicklung bis hin zu von Drittanbietern bezogenen Kernbankensystemen und Fachanwendungen. Mit DORA (Digital Operational Resilience Act) wird diese technische Realität zu einem regulierten IKT‑Risikofaktor.

Der Digital Operational Resilience Act (DORA) schärft die Anforderungen an das IKT-Risikomanagement in Unternehmen. Die Verordnung fordert ein belastbares IKT‑Risikomanagement, ein wirksames Schwachstellen‑ und Änderungsmanagement, regelmäßige Tests der digitalen Resilienz und eine robuste Steuerung von IKT‑Drittparteien. OSS ist Teil dieser regulierten Welt und muss – wie jede andere Software – gezielt eingesetzt und professionell gemanagt werden.

Wer Open Source in kritischen oder wichtigen Funktionen einsetzt, kann sich künftig nicht mehr auf informelle Praktiken verlassen. Professionelles Open Source Management mit Richtlinien, Prozessen, klaren Rollen, einem systematischen Schwachstellenmanagement, gelebter Aktualitätsprüfung und Transparenz in der Inventarisierung durch Software Bill of Materials (SBOM) wird zur Voraussetzung, um DORA-Anforderungen erfüllen zu können.

DORA macht OSS zum IKT‑Risikofaktor 

DORA schafft für Finanzunternehmen ein einheitliches, verbindliches Rahmenwerk für das IKT-Risikomanagement – einschließlich des Umgangs mit Open Source Software. OSS-Komponenten in Anwendungen, Plattformen und Infrastrukturen werden damit zu einem regulierten IKT-Risikofaktor. Finanzunternehmen müssen nachweisen können, dass sie den Einsatz von Open Source Software gezielt steuern und inventarisieren, Schwachstellen systematisch managen und die Aktualität prüfen, um DORA-Compliance sicherzustellen.

Für Unternehmen ergeben sich daraus konkrete Anforderungen: 

• Governance, Richtlinien und Prozesse: Die Nutzung von OSS muss in einen klar definierten IKT-Risikomanagementrahmen eingebettet werden – mit Strategien, Richtlinien und Verfahren, die Open Source explizit adressieren und in bestehende Vorgaben (z. B. Anwendungsentwicklung, IKT-Sicherheit, Schwachstellenmanagement) integriert sind. 
• Schwachstellenmanagement für OSS: Für OSS-Bibliotheken – insbesondere in kritischen und wichtigen Funktionen – sind Verfahren zur kontinuierlichen Erkennung, Bewertung und Behandlung von bekannten Schwachstellen nötig. Dazu gehören automatisierte und regelmäßige Schwachstellen Scans, risikobasierte Bewertung von Findings und nachvollziehbare Entscheidungen zu Updates, Kompensationskontrollen oder Risikoakzeptanz. 
• Aktualitäts- und Patch Management: DORA erwartet, dass die Aktualität von OSS-Komponenten laufend überwacht wird. Unternehmen müssen Releases und Security Patches beobachten, ihre Relevanz bewerten und insbesondere sicherheitskritische Updates zeitnah ausrollen oder begründete Ausnahmen dokumentiert und überwacht führen.
• Inventarisierung von Bibliotheken Dritter: Finanzinstitute müssen die Bibliotheken Dritter, einschließlich Open Source Software-Bibliotheken, fortlaufend identifizieren und nachverfolgen.  
• Schulungen und Awareness: Maßnahmen stellen sicher, dass Personen der Softwareentwicklung, -Architektur, -Betrieb und -Einkauf die besonderen Anforderungen an OSS unter DORA verstehen und in der Praxis anwenden. 

Die Software Bill of Material als zentrales Element für Sicherheit

Die Software Bill of Materials (SBOM) ist das Bindeglied zwischen Transparenz, Schwachstellenmanagement und Aktualität. Sie beschreibt, welche Softwarekomponenten – einschließlich aller OSS‑Bausteine – in einer Anwendung enthalten sind, welche Versionen genutzt werden und wie die Abhängigkeiten miteinander verbunden sind, inklusive transitiver Abhängigkeiten.

Im DORA‑Kontext ermöglicht eine SBOM, neu bekannt gewordene Schwachstellen schnell mit der eigenen Systemlandschaft zu verknüpfen: Ist eine verwundbare Abhängigkeit im Einsatz, in welchen Anwendungen und mit welcher Geschäftsrelevanz und -kritikalität? Wer SBOMs systematisch und zentral nutzt sowie inventarisiert, erhält einen konsolidierten Überblick über alle eingesetzten OSS‑Komponenten und kann Maßnahmen priorisieren.

Die SBOM wird vom technischen Best Practice-Baustein zum notwendigen Bestandteil der Open Source-Analyse, um DORA‑Anforderungen an Schwachstellenmanagement, Inventarisierung und Aktualität gegenüber der Aufsicht belegen zu können. 

Sichern Sie sich Ihre Unterstützung auf dem Weg zum DORA gerechten OSS Management. Wir unterstützen Sie beim Aufbau von Governance, SBOM (SPDX), Schwachstellen und Patch-Management, vertraglichen Anforderungen sowie Schulungen.