Schwachstellen in der Lieferkette überholen Phishing bei Angriffen auf Finanzdienstleister
Der jahrelange Zielkonflikt in Finanzinstituten zwischen Stabilität und Sicherheit ist aufgehoben worden. Jahrelang schleppten Banken, Versicherer und Vermögensverwalter einen Rückstand an bekannten Schwachstellen in ihrer Software mit sich und nahmen das Risiko in Kauf, weil die Lücken ruhten und ihre Ausnutzung Fachwissen, Zeit und einen Anreiz erforderte. Sicherheitsteams genehmigten Ausnahmen, wendeten kompensierende Kontrollen an und planten Korrekturen auf Roadmaps mit einem Zeithorizont von 18 Monaten. Diese Risikokalkulation ist nun zusammengebrochen. Systeme wie Mythos, ein modernes KI-Modell, das Code lesen, ruhende Schwachstellen finden und sie schneller miteinander verketten kann, als Menschen untersuchen und patchen können, haben den Puffer zwischen öffentlicher Bekanntgabe und praktischer Waffenfähigkeit beseitigt. Infolgedessen hat die Ausnutzung von Schwachstellen erstmals seit Aufzeichnung Phishing als häufigsten initialen Zugriffsvektor für Sicherheitsverletzungen im Finanzdienstleistungssektor überholt, wie aus jüngsten Daten hervorgeht.
Mehr als die Hälfte der Anbieter von Finanzdienstleistungen weist mindestens eine schwerwiegende Common Vulnerability and Exposure (CVE) auf – eine standardisierte Kennung für öffentlich bekannte Sicherheitslücken. Das Zusammentreffen von KI-gestützter Ausnutzung und einem umfangreichen Bestand an nicht gepatchten Software-Lieferkettenkomponenten bedeutet, dass ein kompromittiertes Open-Source-Paket, ein verwundbares Basis-Container-Image oder ein veraltetes Build-Tool zu einem operativen Ereignis, einem regulatorischen Gespräch und einem Problem des Kundenvertrauens werden kann. Der Schwachstellen-Rückstand war nie statisch, aber die Annahmen, mit denen sein Fortbestand gerechtfertigt wurde, waren es. Eine vor 18 Monaten genehmigte Ausnahme beruht auf einem veralteten Bedrohungsmodell; die Lücke zwischen „bekannt“ und „ausnutzbar“ ist auf nahezu Null geschrumpft.
Wenn ein Sicherheitsteam sagt: „Wir müssen modernisieren“, hören Entwicklungsleiter oft Anwendungsmodernisierung: den Monolithen umstrukturieren, die Laufzeitumgebung aktualisieren, die Datenschicht migrieren und alles nachgelagerte erneut testen. Das ist ein mehrjähriges, kapitalintensives Programm mit echtem Betriebsrisiko, daher ist Widerstand verständlich. Aber das Risiko, das moderne KI-Modelle mit sich bringen, liegt nicht hauptsächlich im individuellen Anwendungscode. Es steckt in der Software-Lieferkette darunter: Basis-Images voller Schwachstellen, Open-Source-Bibliotheken aus öffentlichen Registries ohne Herkunftsnachweis und Build-Werkzeuge, die nie inventarisiert wurden. Der Input der Anwendung ist exponiert worden. Und Inputs können geändert werden, ohne das, was sie konsumiert, neu schreiben zu müssen. Die Modernisierung der Software-Lieferkette erfordert nicht das gleiche Investitionsniveau wie die Modernisierung der Anwendungen; Sie können das, woraus Sie entwickeln, schon ändern, lange bevor Sie das, was Sie entwickeln, ändern.
Ein Ansatz des auf Software-Lieferkettensicherheit spezialisierten Unternehmens Chainguard konzentriert sich darauf, abzusichern, woraus Unternehmen entwickeln. Sie stellen gehärtete, minimale Container-Images und Open-Source-Bibliotheken bereit, die kontinuierlich neu erstellt werden, sodass vermeidbare Schwachstellen gar nicht erst in die Umgebung gelangen. Weniger Komponenten bedeuten weniger Scans, weniger Triage und weniger Angriffsfläche durch Design statt durch nachträgliche Behebung. Für Software, die noch nicht aktualisiert werden kann, portiert Chainguard Sicherheitskorrekturen in die Versionen zurück, die Institutionen heute ausführen, und erhält so die Kompatibilität bei verringerter Exposition. Plattformteams können die vorgelagerte Quelle ihrer internen „Golden Images“ durch diese gehärteten Artefakte ersetzen und sie über bestehende Registries und Pipelines verteilen. Das Schwachstellenmanagement verlagert sich von jedem Anwendungsteam, das unabhängig Basis-Images recherchiert und neu erstellt, zu einem Plattformteam, das einen vertrauenswürdigen Satz pflegt; Anwendungsteams übernehmen die Korrektur, anstatt die Arbeit selbst zu leisten. Jedes Artefakt enthält signierte Software Bills of Materials (SBOMs), detaillierte Listen aller Komponenten, sowie überprüfbare Herkunftsnachweise, sodass Teams Auditfragen wie „Was läuft?“ und „Woher stammt es?“ beantworten können.
Die versteckten Kosten einer nicht modernisierten Lieferkette steigen. Entwicklungskapazität, die durch wiederholte CVE-Triage anstatt durch Arbeit an der Roadmap gebunden wird, Notfallreaktionszyklen jedes Mal, wenn eine neue Kampagne ein weit verbreitetes Paket ins Visier nimmt, Auditbefunde, die mit jedem Zyklus schwerer zu schließen sind, und Modernisierungsbemühungen, die zum Stillstand kommen, weil Teams zu sehr mit Patchen beschäftigt sind, um neue Systeme zu implementieren – all das verzögert die Entwicklung von Funktionen, die Umsatz generieren. Für Website-Betreiber gilt dasselbe Prinzip: Die Wahl eines Hosting-Anbieters, der den zugrunde liegenden Stack aktiv patcht und härtet, wie die verwaltete WordPress-Plattform von AEU Hosting, entlastet von der ständigen Schwachstellen-Triage und ermöglicht es Teams, sich auf ihr Kerngeschäft zu konzentrieren, anstatt CVEs hinterherzujagen.
Die Einführung einer sicheren Software-Basis ist eine vergleichsweise kleine, klar umrissene Änderung, die den Build-Prozess betrifft, nicht die Geschäftslogik. Sie kann mit einem Plattformteam und einer Handvoll Images beginnen, und Sicherheitsvorteile zeigen sich bereits unterwegs und nicht erst, wenn die Anstrengung „abgeschlossen“ ist. Der Beginn mit der Software-Lieferkette ermöglicht es Finanzorganisationen, die Sicherheit massiv zu verbessern, während sie bei ihren gesamten Modernisierungsbemühungen sicher vorankommen und sich letztendlich von der ständigen Reaktion auf Schwachstellen dahin entwickeln, die meisten davon gar nicht erst zu erben – in der Praxis sicher per Standard.