2026-09-07 • 12 Min. Lesezeit

Der Cyber Resilience Act erreicht das Bankwesen: SBOMs und die Software-Lieferkette

Am 11. September 2026 greifen die Meldepflichten des EU Cyber Resilience Act, am 11. Dezember 2027 der Rest. Die meisten Banken haben den CRA unter „Produktregulierung, betrifft uns nicht“ abgelegt. Das war eine vertretbare erste Lesart – und eine teure zweite. Denn der CRA schreibt neu, was jeder Lieferant Ihnen schuldet, während DORA Sie längst dafür haftbar macht, was diese Lieferanten ausliefern.

Die Frist, die niemand in die Bankenroadmap geschrieben hat

Die Verordnung (EU) 2024/2847 – der Cyber Resilience Act – trat im Dezember 2024 mit langem Vorlauf in Kraft, und die meisten Finanzinstitute lasen sie als fremdes Problem. Regulierungsgegenstand ist das Produkt mit digitalen Elementen, das auf dem EU-Markt bereitgestellt wird: Router, Industriesteuerungen, Betriebssysteme, Bibliotheken, Firmware. Eine Bank stellt auf den ersten Blick nichts davon her. Die Pflichten schienen bei den Anbietern zu liegen, und der Vorgang wanderte auf den Stapel „beobachten“.

Dieser Stapel ist inzwischen überfällig. Ab dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die Single Reporting Platform der ENISA melden – im Takt von 24 Stunden, 72 Stunden und 14 Tagen. Ab dem 11. Dezember 2027 gelten die grundlegenden Anforderungen und die CE-Kennzeichnung vollständig. Zwischen diesen Daten baut jeder ernsthafte Lieferant im Bankenbestand um, wie er Komponenten dokumentiert, Schwachstellen offenlegt und Supportzeiträume zusagt. Institute, die den CRA für ein Lieferantenthema hielten, werden feststellen: Er kommt als Vertragsthema an, als Incident-Response-Thema – und bei manchen mit dem eigenen Namen darauf.

Was der CRA reguliert – und ob er Sie reguliert

Der CRA erfasst das in Verkehr gebrachte Produkt, nicht den für Kunden betriebenen Dienst. Reines Software-as-a-Service fällt heraus – das ist NIS2-Terrain – es sei denn, es handelt sich um eine Fernverarbeitungslösung, ohne die das Produkt seine Funktion nicht erfüllen kann. Freie und quelloffene Software, die außerhalb einer Geschäftstätigkeit bereitgestellt wird, liegt ebenfalls außerhalb des Anwendungsbereichs, mit einem bewusst leichteren Regime für Open-Source-Verwalter. Für den größten Teil des internen Bestands einer Bank – Kernbanksystem, Datenplattform, interne Portale – bindet der CRA den Lieferanten, nicht den Betreiber.

Die Randfälle verdienen ein Rechtsgutachten statt einer Annahme. Eine Retail-Banking-App, die über öffentliche App Stores vertrieben wird; ein White-Label-Terminal, das an Händler ausgeliefert wird; ein Payment-SDK, das Firmenkunden erhalten; ein API-Gateway, das an eine Tochtergesellschaft in einem anderen Mitgliedstaat lizenziert wird – all das sieht eher nach Software aus, die im Rahmen einer Geschäftstätigkeit auf dem Markt bereitgestellt wird, als nach einem internen Dienst. Die Antwort ist institutsspezifisch, aber die Frage hat eine Frist, und „wir sind davon ausgegangen, nicht betroffen zu sein“ ist im Dezember 2027 eine schwache Position.

Das SBOM ist keine Kür mehr

Anhang I verpflichtet Hersteller, die in ihren Produkten enthaltenen Komponenten zu ermitteln und zu dokumentieren, unter anderem durch Erstellung einer Software-Stückliste in einem gängigen, maschinenlesbaren Format, das zumindest die Abhängigkeiten der obersten Ebene abdeckt. Diese Formulierung lohnt langsames Lesen. Maschinenlesbar heißt SPDX oder CycloneDX, nicht eine Tabelle im E-Mail-Anhang. Das SBOM muss über den gesamten Supportzeitraum aktuell bleiben – mindestens fünf Jahre oder die erwartete Lebensdauer, falls kürzer – und ist Teil der technischen Dokumentation, die zehn Jahre aufzubewahren ist.

Bei „zumindest“ beginnt die Diskussion. Log4Shell war in den betroffenen Beständen keine Abhängigkeit der obersten Ebene, sondern saß drei oder vier Ebenen tiefer: in einer Logging-Fassade, in einem Framework, in einem Applikationsserver. Ein SBOM, das bei den direkten Abhängigkeiten endet, erfüllt den Buchstaben von Anhang I und beantwortet fast keine der Fragen, die um zwei Uhr nachts während einer aktiv ausgenutzten Schwachstelle gestellt werden. Banken, die SBOMs von Lieferanten erhalten, sollten die Tiefe vertraglich festlegen – die Verordnung setzt eine Untergrenze und wird sie nicht für sie anheben.

Zwei Uhren, ein Vorfall

Eine einzige ausgenutzte Schwachstelle in einer zugelieferten Komponente kann zwei regulatorische Uhren starten, die nicht übereinstimmen. Nach CRA Artikel 14 schuldet der Hersteller eine Frühwarnung binnen 24 Stunden nach Kenntnisnahme, eine ausführlichere Meldung binnen 72 Stunden und einen Abschlussbericht binnen 14 Tagen, nachdem eine Korrekturmaßnahme verfügbar ist – einmal eingereicht, an das federführende CSIRT und an die ENISA. Nach DORA Artikel 19 und den zugehörigen technischen Standards schuldet die Bank ihrer zuständigen Behörde eine Erstmeldung binnen vier Stunden nach Einstufung des Vorfalls als schwerwiegend und spätestens 24 Stunden nach Kenntnisnahme, einen Zwischenbericht binnen 72 Stunden und einen Abschlussbericht einen Monat nach dem letzten Zwischenbericht.

Die Uhren unterscheiden sich in Auslöser, Adressat und Inhalt – und laufen gleichzeitig über denselben Sachverhalt. Erschwerend kommt hinzu, dass die Vier-Stunden-Uhr der Bank häufig vor der Offenlegung des Herstellers zu laufen beginnt, weil Institute in der Regel aus der eigenen Telemetrie lernen und nicht aus einer Lieferantenmitteilung. Die Antwort im Betriebsmodell ist kein zweites Meldeteam. Sie ist ein einziger Vorfallsdatensatz mit zwei Ausgabepfaden, ein Triage-Schritt, der DORA-Wesentlichkeit und CRA-Relevanz gemeinsam bewertet, und vertragliche Meldefenster, die Lieferanten verpflichten, innerhalb Ihrer Frist zu informieren – nicht innerhalb ihrer eigenen.

Die neuen Pflichten Ihrer Lieferanten sind Ihr Hebel

Das Wertvollste, was der CRA für eine Bank leistet, ist, verhandelbar zu machen, was bisher im Ermessen des Anbieters lag. Ab Dezember 2027 muss ein konformer Hersteller eine Richtlinie zur koordinierten Offenlegung von Schwachstellen betreiben, Sicherheitsupdates über einen erklärten Supportzeitraum von mindestens fünf Jahren bereitstellen, Produkte mit sicheren Standardkonfigurationen ausliefern und ein maschinenlesbares SBOM übergeben. Das waren früher Verhandlungswünsche, die ein selbstbewusster Anbieter schlicht ablehnen konnte. Sie werden zur Bedingung für den Marktzugang.

Der praktische Zug ist, diese Punkte jetzt in den Einkauf zu ziehen, statt den Zeitplan des Anbieters für 2027 zu erben. Klauseln, die sich in diesem Quartal lohnen: SBOM-Lieferung zu jedem Release in festgelegter Tiefe und festgelegtem Format; ein erklärtes Support-Enddatum statt eines gleitenden Versprechens; Meldung aktiv ausgenutzter Schwachstellen innerhalb eines Fensters, das mit den vier Stunden aus DORA vereinbar ist; und CRA-Konformitätszusicherungen für alles, was nach Dezember 2027 in Verkehr gebracht wird. Dieselbe Arbeit speist das DORA-Informationsregister: Die Lieferantenfakten, die der CRA ans Licht zwingt, sind weitgehend jene, die das Register ohnehin verlangt.

Die Technik hinter dem Papier

Für Institute, die tatsächlich Produkte im Anwendungsbereich in Verkehr bringen, sind Compliance-Artefakte nur glaubwürdig, wenn sie erzeugt und nicht zusammengetragen werden. Ein SBOM, das in der Woche vor dem Audit von Hand erstellt wird, ist ein Dokument. Ein SBOM, das die Build-Pipeline ausgibt, signiert, attestiert und neben dem beschriebenen Artefakt ablegt, ist eine Kontrolle. Dasselbe gilt für den Umgang mit Schwachstellen: Eine Richtlinie zur koordinierten Offenlegung bleibt ein PDF, bis es einen Eingangskanal gibt, eine Triage-Rufbereitschaft, ein Schweregradschema und einen gemessenen Weg von der gemeldeten CVE zum ausgelieferten Patch.

Was Bereitschaft von Papierarbeit trennt, ist Abfragbarkeit. Wenn das nächste Log4Shell einschlägt, lautet die Frage: Welche unserer Releases enthalten diese Komponente in welcher Tiefe, in welchen Umgebungen – und welche Kunden betreiben sie? Das in Minuten zu beantworten verlangt einen SBOM-Speicher über Versionen hinweg und eine VEX-Praxis, die je Produkt festhält, ob eine gelistete CVE dort tatsächlich ausnutzbar ist. Ohne VEX erzeugt ein tiefes SBOM vor allem Rauschen – und Rauschen ist genau das, was eine 24-Stunden-Frist unerreichbar macht.

Fünfzehn Monate bis Dezember 2027

Die Reihenfolge ergibt sich von selbst, sobald die Anwendungsbereichsfrage beantwortet ist. Von jetzt bis Ende 2026: mit der Rechtsabteilung klären, ob ein vom Institut in Verkehr gebrachtes Produkt in den Anwendungsbereich fällt, und die CRA-Relevanz in die bestehende DORA-Vorfallstriage aufnehmen, damit beide Bewertungen in einem Durchgang erfolgen. Im ersten Halbjahr 2027: Einkaufsvorlagen neu schreiben und SBOMs von den zehn Lieferanten einfordern, deren Software den kritischen oder wichtigen Funktionen am nächsten steht – nicht weil die Verordnung sie schon zwingt, sondern weil zehn echte SBOMs mehr lehren als jedes Readiness-Assessment.

Das zweite Halbjahr 2027 gehört der bestandsweiten Arbeit: ein SBOM-Repository, das abgefragt und nicht abgeheftet wird, VEX für die Produkte, die Sie ausliefern, und Konformitätsnachweise für alles im Anwendungsbereich. Nichts davon ist exotische Technik, und das meiste lohnt sich aus eigenem Recht – das ist das ehrliche Argument für einen frühen Start. Die Frist des CRA ist ein Auslöser für eine Fähigkeit, die Banken ohnehin brauchten: genau und schnell zu wissen, woraus ihre Software tatsächlich besteht.