Warum Open-Source-Patches in Banken oft nicht ankommen

Im Rahmen des Open Source Summit Europe 2026 in Prag hat Gabriele Columbro (Executive Director der FINOS – Fintech Open Source Foundation) erste Ergebnisse des Projektes OSERA Risk Navigator vorgestellt. Die Open Source Enterprise Resiliency Alliance (OSERA) will Firmen in stark regulierten Umgebungen beim Schließen von Sicherheitslücken von quelloffener Software helfen. Dabei liegt der momentane Fokus auf Banken und vergleichbaren Finanzinstituten.

Warum Sicherheitslücken in Banken lange offenbleiben

Wo liegt das Problem? Es ist bekannt, dass es Wochen, Monate, manchmal sogar Jahre dauern kann, bis ein Sicherheitspatch aus dem Quellcode-Repository in der Produktivumgebung einer Bank landet. Es ist aber noch schlimmer, denn oft genug patchen die Firmen die Software selbst. Allerdings bleibt diese Änderung der Community verborgen. Die Banken verfolgen folgende Prozedur: Klonen, Patchen, Neuabgleich mit dem offiziellen Repo, Patchen, … und so weiter. Auf diese Weise – und das ist nur ein fiktives Beispiel – kann eine Bank auch im Jahr 2026 noch einen Apache-Webserver in der Version 2.2.x betreiben. Sprich: es gibt Software in einem öffentlich unbekannten Zustand in der IT von Finanzinstituten. Dieser Zustand ist nicht neu und ließ sich bis vor ein paar Monaten auch „wegdiskutieren“.

Doch auch hier hat die künstliche Intelligenz die Rahmenbedingungen deutlich verändert. Die Veröffentlichung von Claude Mythos hat das Thema Patchen auf die Agenda der Chefetagen der Banken gesetzt. „Verstecken“ und „Wegducken“ geht nicht mehr. Die KI kann Schwachstellen innerhalb von Tagen, wenn nicht Stunden, finden und beim Erstellen von Schadcode helfen. Damit haben die Banken nun quasi die Hausaufgaben von Jahren zu erledigen.

Wie der Risk Navigator beim Patchen helfen soll

Genau hier will der OSERA Risk Navigator helfen. Dieser erfüllt drei grundlegende Aufgaben. Da ist das Erfassen der Ist-Situation: Welche Dateien und Bibliotheken sind verwundbar? Danach kommt das Priorisieren des Patches: Was lässt sich einfach beziehungsweise schnell beheben? Zum Schluss folgt das Zusammenfassen der Korrekturen, sodass es operativ planbar ist. Eine fundamentale Säule für den Risk Navigator sind die SBOMs (Software Bills of Materials) der Banken. So „weiß“ der Risk Navigator welche Software und in welcher Version im Einsatz ist. Die Übermittlung dieser SBOMs erfordert ein gewisses Vertrauen der Banken in OSERA. In der Pilotphase haben die Firmen deshalb das Werkzeug im eigenen Rechenzentrum laufen lassen und repräsentative Anwendungen ausgewählt. Mit diesen Informationen führt der Risk Navigator einige Prüfungen durch. Gibt es inzwischen einen offiziellen Patch – eventuell einer neuen Version? Ist gegebenenfalls ein Backport möglich? Dazu gehört natürlich eine Bewertung der Gefährlichkeit der Sicherheitslücke gemäß CVSS, EPSS, CISA KEV und mehr. So lassen sich die zu schließenden Sicherheitslücken einordnen und priorisieren. Damit lässt sich der Aufgabenberg in Kategorien wie Dringend, Wichtig, Kann-Warten und so weiter unterteilen.

Viele der verwendeten Informationen liegen den Firmen in dem einen oder anderen System sicher schon vor. Was ist also der Unterschied bei der Verwendung des Risk Navigators? Da ist einmal die enge Verzahnung mit den Open-Source-Projekten, die den ursprünglichen Code verwalten und weiter entwickeln. OSERA verwaltet aber auch die Kommunikation mit Software-Herstellern. Damit ist der Risk Navigator eine Art Broker zwischen den Banken und den verschiedenen Akteuren im Open-Source- und Software-Bereich.

Und das Ganze klingt nicht nur auf dem Papier gut. Wie schon angedeutet, haben die ersten großen Banken die Pilotphase abgeschlossen und ihre SBOMs übermittelt und sind willens die weiteren Schritte bis zum Patch beziehungsweise Aktualisieren zu gehen. Im Gespräch mit iX zeigt sich Gabriele Columbro sehr erfreut über diesen Meilenstein. Er verriet auch, dass die Arbeiten zum Risk Navigator auch ohne KI wichtig waren. Das Erscheinen von Claude Mythos hatte eine enorme Katalysator-Wirkung, um die Banken an den Gesprächstisch zu bekommen. Wer sich selbst einen ersten Einblick verschaffen will, kann die Web-Demo inspizieren oder aber die Quellen aus dem GitHub-Repo ziehen und testen.