Die zunehmende Komplexität der IT-Infrastrukturen im Finanzsektor erfordert eine gründliche Bewertung von Softwareabhängigkeiten. Mit dem Digital Operational Resilience Act (DORA) werden die Verwaltung von Drittanbieter-Bibliotheken und die Open-Source-Analyse zu zentralen Elementen bei der Gewährleistung der operativen Resilienz und der Sicherheit digitaler Vermögenswerte, wie in Artikel 25 der Verordnung vorgesehen.

Durch DORA geforderte Open-Source-Analyse

DORA legt fest, dass Analysen von Open-Source-Software in das Programm zur Prüfung der digitalen operativen Resilienz aufgenommen werden müssen. Ziel ist es, die Risiken im Zusammenhang mit der Software-Lieferkette zu steuern: Eine Schwachstelle in einer gemeinsam genutzten Bibliothek kann die gesamte Infrastruktur eines Finanzunternehmens gefährden. Gemäß den regulatorischen Anforderungen ermöglicht die Open-Source-Analyse die frühzeitige Identifizierung von Sicherheitslücken in Drittanbieter-Komponenten, um die Kontrolle über operative Risiken zu behalten.

Softwareabhängigkeiten und Delegierte Verordnung (EU) 2024/1773

Die Delegierte Verordnung (EU) 2024/1773 verpflichtet Finanzunternehmen dazu, den Quellcode sowie proprietäre Software von Dritten oder aus Open-Source-Projekten vor der Inbetriebnahme auf Schwachstellen und bösartigen Code zu untersuchen. Gefordert sind statische und dynamische Tests, die Erkennung von Anomalien sowie die Einführung von Sanierungsplänen (Remediation).

Inventarisierung von Abhängigkeiten und Überwachung von CVE-Schwachstellen

Ein effektives Management von Abhängigkeiten erfordert die systematische Nachverfolgung von Drittanbieter-Bibliotheken, die Überwachung von Versionen, zeitnahe Aktualisierungen sowie die präzise Protokollierung jeder Schwachstelle, die sich auf IKT-Systeme auswirkt. Die Verfahren müssen Folgendes vorsehen:

• Ständige Überwachung und Nachverfolgung von Bibliotheken, einschließlich Open-Source-Komponenten, mit entsprechender Verwaltung der Updates.
• Registrierung jeder erkannten Schwachstelle.
• Priorisierung der Patch-Verteilung basierend auf der Kritikalität der Schwachstelle und dem Risikoprofil der betroffenen Vermögenswerte.
• Bei kritischen oder relevanten Vermögenswerten muss die Überwachung streng sein; bei nicht-kritischen Off-the-Shelf-Assets sollte die Nachverfolgung dennoch nach Möglichkeit gewährleistet werden.

SBOM: Stand der Technik für die Compliance

Obwohl DORA und die RTS die SBOM (Software Bill of Materials) nicht explizit erwähnen, macht die Notwendigkeit, Bibliotheken und Versionen nachzuverfolgen, die SBOM zum effektivsten und am weitesten verbreiteten technischen Standard zur Sicherstellung der Compliance. Eine SBOM fungiert als vollständiges Inventar der Softwarekomponenten und erleichtert die proaktive Überwachung sowie die zeitnahe Reaktion auf neue öffentliche Schwachstellen (CVEs), die spezifische, vom Unternehmen verwendete Bibliotheken betreffen.

Integration in den SDLC und das Patch-Management

Die durch DORA geforderte Open-Source-Analyse muss in den Softwareentwicklungslebenszyklus (SDLC) integriert werden. Unternehmen sind verpflichtet, die Integrität des Quellcodes – sowohl intern als auch von Drittanbietern – zu schützen und diese Aktivitäten mit dem Patch-Management zu verknüpfen. Software-Updates müssen vor der Bereitstellung in der Produktion in repräsentativen Staging-Umgebungen getestet und implementiert werden, um betriebliche Unterbrechungen zu vermeiden. Wenn eine Open-Source-Schwachstelle nicht durch einen Patch behoben werden kann, ist es zwingend erforderlich, andere Minderungsmaßnahmen zu identifizieren und zu aktivieren.

FAQ

• Schreibt DORA eine SBOM vor?
• Die Verordnung verlangt die Nachverfolgung der Nutzung von Drittanbieter- und Open-Source-Bibliotheken sowie die Überwachung von deren Versionen und Updates. Obwohl der Begriff “SBOM” nicht explizit verwendet wird, stellt die Erstellung einer Stückliste der Software die effektivste technische Lösung dar, um diese Anforderung zu erfüllen.
• Wie geht man mit Bibliotheken in Legacy-Anwendungen um?
• Unternehmen müssen überwachen, ob IKT-Assets noch von Anbietern oder Entwicklern unterstützt werden. Für Legacy-Assets oder solche, die nicht mehr unterstützt werden, ist ein Risikomanagementplan unerlässlich, der deren Veralterung abfedert.
• Ersetzt die Open-Source-Analyse den Penetrationstest?
• Nein. Die Open-Source-Analyse konzentriert sich auf Abhängigkeiten und den Code und ist Teil der ordentlichen Resilienztests gemäß Artikel 25. Diese Aktivitäten müssen durch Schwachstellenanalysen (Vulnerability Assessments) und Penetrationstests ergänzt werden, um die allgemeine Sicherheit der Systeme zu bewerten.

Steuern Sie Ihre Software-Lieferkette: Fordern Sie eine Überprüfung des Softwarerisikos und der kritischen Abhängigkeiten an, um Ihre Entwicklung an die Sicherheitsanforderungen von DORA anzupassen.