Supply-Chain-Angriffe auf Finanzinstitute um 78 % gestiegen: Warum Banken Security-First-Softwarepartner brauchen

Supply-Chain-Angriffe auf Finanzinstitute stiegen zwischen 2024 und 2025 um 78 %, wobei die SEC nun registrierten Unternehmen vorschreibt, wesentliche Cybersicherheitsvorfälle innerhalb von vier Werktagen zu melden. Der Finanzdienstleistungssektor ist zum primären Ziel geworden, weil er hochwertige Transaktionssysteme, dichte Vernetzung mit Drittanbietern und regulatorische Einschränkungen kombiniert, die das Sicherheitspatching manchmal verlangsamen.

Für Finanzinstitute, die Softwareentwicklungspartner bewerten, ist die Supply-Chain-Sicherheitsposition ihrer Anbieter nicht mehr ein Beschaffungs-Checkbox — sie ist ein existenzieller Risikofaktor. Ein kompromittierter Entwicklungspartner liefert eine Hintertür in Produktivumgebungen und setzt potenziell Kundendaten, Zahlungssysteme und regulatorische Infrastruktur der Kontrolle durch Angreifer aus.

Die Supply-Chain-Bedrohungslandschaft im Finanzsektor

Angriffsmuster 2025–2026

Die Angriffsmuster, die auf Finanzinstitute über ihre Software-Supply-Chains abzielen, haben sich signifikant weiterentwickelt. Drei dominante Modalitäten definieren nun die Bedrohungslandschaft.

Dependency Confusion und Typosquatting-Angriffe gegen Package Registries verbreiten sich weiter. Im Q3 2025 veröffentlichte eine koordinierte Kampagne bösartige Pakete auf npm mit Namen, die populären Finanz-Datenverarbeitungsbibliotheken ähnelten. Die Pakete führten korrekt aus, exfiltrierten aber gleichzeitig Umgebungsvariablen, API-Schlüssel und Datenbankverbindungsstrings. Mindestens 14 Fintech-Unternehmen wurden vor der Erkennung kompromittiert.

CI/CD-Pipeline-Kompromittierung hat sich als zweiter Hauptvektor herausgebildet. Angreifer, die Zugang zur Build-Infrastruktur erlangen, injizieren bösartigen Code während der Kompilierung und produzieren Artefakte, die Code-Reviews bestehen, weil die Ergänzungen nur im gebauten Output existieren. Mehrere Vorfälle im Jahr 2025 betrafen kompromittierte GitHub-Actions-Runner und Jenkins-Build-Agents bei Anbietern, die Finanzinstitute bedienen.

Der dritte und heimtückischste Vektor ist die Maintainer-Kompromittierung — Account-Übernahme, Social Engineering oder direkte Anwerbung legitimer Open-Source-Maintainer. Die im März 2024 entdeckte xz-Utils-Backdoor zeigte, dass ein geduldiger Angreifer Jahre damit verbringen konnte, Vertrauen aufzubauen, bevor er eine ausgeklügelte Hintertür einführte.

Finanzinstitute operieren jetzt unter der Annahme, dass jede Abhängigkeit kompromittiert sein könnte.

Regulatorische Reaktion

Regulierungsbehörden haben mit zunehmend vorschreibenden Anforderungen reagiert.

Der Digital Operational Resilience Act (DORA) der EU trat im Januar 2025 vollständig in Kraft und verpflichtet Finanzunternehmen, ein Register aller IKT-Drittanbietervereinbarungen zu führen, vorvertragliche Sicherheits-Due-Diligence durchzuführen und eine laufende Überwachung der Anbieter-Sicherheitsposition vorzunehmen.

In den Vereinigten Staaten verlangen die Cybersicherheits-Offenlegungsvorschriften der SEC nun, dass registrierte Unternehmen Prozesse zum Management von Drittanbieter-Cybersicherheitsrisiken beschreiben. Börsennotierte Finanzunternehmen müssen die Sicherheitspraktiken ihrer Softwareentwicklungspartner formal dokumentieren.

SBOM-Anforderungen wandeln sich von Empfehlung zu Pflicht. CISAs Leitlinien, der EU Cyber Resilience Act und sektorspezifische Mandate konvergieren auf einer gemeinsamen Erwartung: Jede Softwarelieferung muss ein maschinenlesbares Inventar aller Komponenten und ihres bekannten Schwachstellenstatus enthalten.

Security-First-Entwicklung: Was es tatsächlich bedeutet

Viele Softwareunternehmen vermarkten „Security-First"-Praktiken, die auf Compliance-Theater hinauslaufen — ein jährlicher Penetrationstest, ein SOC-2-Type-II-Bericht und Entwickler-Sicherheitsschulung. Diese Grundlagen sind notwendig, aber radikal unzureichend für Organisationen, die Finanztransaktionssoftware entwickeln.

Sicherheit auf Architekturebene

Echte Security-First-Entwicklung erfordert Threat Modeling jedes Features vor der Implementierung, das Design von Datenflüssen, die den Blast Radius minimieren, die Implementierung von Defense in Depth und die Auswahl von Technologie-Stacks basierend auf ihrem Sicherheits-Track-Record.

Auf Implementierungsebene bedeutet es obligatorische Code-Reviews mit sicherheitsfokussierten Reviewern, automatisierte statische Analyse integriert in CI/CD und Entwicklungsumgebungen, die Produktiv-Sicherheitskontrollen widerspiegeln.

Abhängigkeitsmanagement

Die wirkungsvollste einzelne Praxis zur Supply-Chain-Risikoreduktion ist rigoroses Abhängigkeitsmanagement:

• Pflege vollständiger, kontinuierlich aktualisierter Inventare aller direkten und transitiven Abhängigkeiten
• Nutzung von Lockfiles und gepinnten Versionen zur Verhinderung unautorisierter Updates
• Laufendes automatisiertes Schwachstellen-Scanning mit Blocking-Policies für kritische Schwachstellen
• Evaluierung der Maintainer-Community-Gesundheit vor der Übernahme neuer Pakete

SBOM-Generierung sollte als Teil des Build-Prozesses automatisiert werden und Inventare im SPDX- oder CycloneDX-Format produzieren. Entscheidend ist, dass SBOMs aus tatsächlichen Build-Artefakten generiert werden — nicht allein aus Quellcode —, um Diskrepanzen zu erkennen, die durch Build-System-Kompromittierung eingeführt wurden.

Bewertung von Softwareentwicklungspartnern

Technische Sicherheitsindikatoren

Finanzinstitute sollten spezifische technische Indikatoren bewerten, die die Sicherheitsreife eines Anbieters jenseits von Marketingaussagen und Compliance-Zertifizierungen offenbaren.

Sicherheitsindikator	Worauf zu achten ist
Build-System-Integrität	Reproduzierbare Builds mit kryptografischer Verifikation
Code-Signierung	Lieferungen signiert über Hardware Security Modules
Credential Management	Vault-basierte Secrets mit Audit-Logging und Rotation
Incident Response	Dokumentierte, getestete Pläne für Supply-Chain-Kompromittierung
Dev-Umgebungssicherheit	Gehärtete Workstations, Netzwerksegmentierung, MFA

Reproduzierbare Builds sind die stärkste Verteidigung gegen Build-System-Kompromittierung. Anbieter, die sie implementieren, demonstrieren sowohl technische Raffinesse als auch echtes Engagement für Supply-Chain-Integrität.

Vertragliche Anforderungen

DORA verlangt spezifisch bestimmte vertragliche Bestimmungen für IKT-Drittanbietervereinbarungen. Zentrale Elemente umfassen:

• Verpflichtende Vorfallbenachrichtigung innerhalb von Stunden nach der Erkennung
• Regelmäßige Rechte zur Sicherheitsbewertung einschließlich Penetrationstests
• SBOM-Lieferung mit jedem Release und kontinuierliche Schwachstellenüberwachung
• Definierte Sicherheits-SLAs — 24 Stunden für aktiv ausgenutzte Schwachstellen, 72 Stunden für kritische Befunde
• Kündigungsbestimmungen, die die operative Kontinuität schützen

Aufbau einer Security-First-Kultur

Technische Kontrollen können ohne unterstützende Organisationskultur nicht funktionieren. Security-First ist keine Tooling-Entscheidung — es ist eine Verpflichtung, die sich in Einstellung, Leistungsbewertung und Ressourcenallokation manifestiert.

Entwicklungsorganisationen, die Sicherheit wirklich priorisieren:

• Reservieren Engineering-Zeit für Sicherheitsarbeit als Aktivität erster Klasse

• Investieren in fortlaufendes praxisnahes Sicherheitstraining über Compliance-Anforderungen hinaus

• Halten dedizierte Security-Engineering-Kapazitäten vor

• Verfolgen Sicherheitsmetriken mit derselben Rigorosität wie bei der Liefergeschwindigkeit

Für Finanzinstitute, die Entwicklungspartner suchen, muss die Bewertung über Fragebögen hinausgehen und direkte Beobachtung der Engineering-Praktiken, Überprüfung des tatsächlichen Sicherheits-Toolings und Gespräche mit dem Security-Engineering-Team des Anbieters umfassen.

Die besten Fintech-Softwareentwicklungsunternehmen in Europa differenzieren sich zunehmend durch nachweisbare Security-Engineering-Fähigkeiten, die weit über Compliance-Grundlagen hinausgehen.

Die Kosten des Scheiterns

Die finanziellen Auswirkungen eines Supply-Chain-Versagens gehen weit über die unmittelbare Incident Response hinaus.

Für das kompromittierte Institut:

• Regulatorische Strafen von bis zu 2 % des globalen Jahresumsatzes unter DORA

• Kundenbenachrichtigungspflichten über mehrere Jurisdiktionen hinweg

• Reputationsschaden, der das Kundenvertrauen erodiert

• Operative Unterbrechung, während kompromittierte Systeme isoliert und neu aufgebaut werden

Für den verantwortlichen Anbieter:

• Verlust der Kundenbeziehung und potenzielle rechtliche Haftung

• Reputationsschaden, der sich schnell durch das Anbieter-Ökosystem im Finanzsektor ausbreitet

• Regulatorische Prüfung unter DORAs Aufsichtsrahmen

Die Ökonomie ist eindeutig: Investitionen in Security-First-Praktiken und die Auswahl von Anbietern nach rigorosen Kriterien kosten einen Bruchteil dessen, was eine einzelne Supply-Chain-Kompromittierung an finanziellen, regulatorischen und reputationsbezogenen Schäden verursacht.

In einem Bedrohungsumfeld, in dem Angriffe um 78 % pro Jahr zunehmen, ist Sicherheit kein Feature — sie ist das Fundament, auf dem jedes andere Feature aufbaut.

Veröffentlicht am 27. Februar 2026 · SectorPunk Research