5 Gründe, warum Entwickler in Finanzinstituten ihren Security-Teams voraus sind

Fortschrittliche Biometrie. Nahtlose Onboarding-Prozesse. Plattformübergreifende Integrationen. Hochgradig personalisierte Dashboards. Klar gestaltete Berichte.

Das sind nur einige der Funktionen, die Nutzer heute von ihren Finanzanwendungen erwarten. Deshalb müssen die meisten Finanzinstitute sie schnell bereitstellen – andernfalls laufen sie Gefahr, von FinTech-Disruptoren überholt zu werden, die dies bereits tun. Entwicklungsteams müssen daher schneller entwickeln und neue Technologien einsetzen, um anspruchsvolle Ziele und enge Fristen einzuhalten.

Doch während Entwickler in Finanzinstituten schnell neue Technologien und Prozesse einführen, um mit diesem Innovationstempo Schritt zu halten, kommen ihre Security-Kollegen oft kaum hinterher. Viele versuchen, ältere Technologien auf neue Entwicklungsumgebungen anzuwenden, und beeinträchtigen damit unbeabsichtigt das Geschäftsergebnis.

Warum funktionieren bewährte Tools und Prozesse für die Anwendungssicherheit bei diesen Security-Teams nicht? Werfen wir einen Blick auf einige Realitäten der heutigen Entwicklungspipelines im Finanzsektor.

Infrastructure as Code (IaC) wird von Entwicklern verwaltet und bereitgestellt.

Da viele Unternehmen ihre Infrastruktur heute in cloudbasierter IaC statt auf Hardware oder in Rechenzentren hosten, liegt die Hauptverantwortung dafür inzwischen beim Entwicklungsteam. Entwickler in Finanzinstituten bilden da keine Ausnahme. IaC ist zudem anfällig für Software-Schwachstellen – ein Risiko, das bei lokal gehosteter Infrastruktur nicht bestand.

Deshalb müssen die Security-Teams dieser Entwickler IaC in ihre Initiativen zur Anwendungssicherheit einbeziehen. Viele ältere Technologien berücksichtigen IaC und die möglichen Angriffsvektoren jedoch nicht.

Apps werden in komplexen Multi-Cloud-Umgebungen gehostet.

Jedes Entwicklungsteam in einem großen Finanzinstitut arbeitet wahrscheinlich mit einer etwas anderen Pipeline und unterschiedlichen Technologien und Integrationen. Jede Pipeline ist eine gut geölte Hochgeschwindigkeitsmaschine. Entwickler erledigen ihre Aufgaben in der Regel in einer festgelegten integrierten Entwicklungsumgebung (IDE), sodass sie beim Zusammenstellen von Software in einen Flow-Zustand kommen können.

Die Security-Teams, die für den Schutz dieser Software verantwortlich sind, reagieren auf die Vielzahl an Pipelines auf eine von zwei Arten.

1. Sie versuchen, mit einer einheitlichen Security-Oberfläche für alle Technologie-Stacks gleiche Bedingungen zu schaffen. Für Entwickler ist dieser Prozess jedoch oft frustrierend, weil sie dafür ihren Flow unterbrechen und sich bei einer völlig anderen Plattform anmelden müssen.

2. Sie passen ihre Security-Tools manuell an jede einzelne Pipeline an. Das kann das Security-Team jedoch überfordern, da es diese manuelle Arbeit für jede Entwicklungspipeline im Unternehmen erledigen muss.

Ältere Tools lassen Security-Teams oft nur diese beiden Möglichkeiten, da sie nicht dafür entwickelt wurden, die Komplexität und Vielfalt cloudbasierter Entwicklungs-Workflows problemlos zu unterstützen.

Microservices-Architekturen sind weit verbreitet.

Auch in schnelllebigen Entwicklungspipelines sind Microservices-Architekturen üblich. Diese Funktionen helfen Entwicklern, ihre Prozesse zu beschleunigen und die hohe Kundennachfrage zu bedienen. Sie bringen jedoch auch zusätzliche Sicherheitsrisiken mit sich, etwa Schwachstellen in Container-Images und übermäßig freizügige Kommunikation zwischen Containern.

Herkömmliche Security-Tools übersehen häufig diese neuen Arten von Container-Schwachstellen. Außerdem können sie nicht unterscheiden, was bei einer Microservices-Architektur „normal“ ist und was auf Sicherheitsprobleme hindeutet. Das führt zu Fehlalarmen und einer Flut von Warnmeldungen.

Automatisierung spielt in der Entwicklung eine zentrale Rolle.

Entwicklungsteams, die mit FinTech-Disruptoren Schritt halten wollen, setzen ebenfalls stark auf Automatisierung, etwa auf CI/CD-Tools, um leistungsstarke Finanzfunktionen in großem Maßstab bereitzustellen. Das hat einige Folgen für Security-Teams. Zum einen entstehen neue Risiken, denn ein Fehler in einem Teil der CI/CD-Pipeline kann den gesamten Prozess gefährden. Zum anderen müssen Security-Tools mit diesen automatisierten Schritten Schritt halten. Manuell gesteuerte Tools und langwierige Audits eignen sich nicht für automatisierte Pipelines.

Generative KI ermöglicht neue Geschwindigkeiten.

In letzter Zeit haben sich Entwicklungspipelines auch durch KI-Coding-Assistenten beschleunigt. Die meisten Entwickler verlassen sich stark auf diese Assistenten und vertrauen ihnen oft zu, qualitativ hochwertigen, sicheren Code zu schreiben – obwohl das häufig nicht der Fall ist. Mit diesen KI-gestützten Tools erzeugen sie First-Party-Code viel schneller, als Menschen allein Software entwickeln könnten.

Ältere Tools, die darauf ausgelegt sind, von Menschen geschriebenen First-Party-Code zu schützen, können deshalb nicht mithalten. Sie sind nicht dafür konzipiert, die enormen Code-Mengen abzusichern, die KI-Coding-Assistenten erzeugen können.

Neue Entwicklungspraktiken erfordern neue Sicherheitsansätze

Wenn Security-Teams in Finanzinstituten nicht über die passenden Tools und Prozesse verfügen, werden sie von den ambitionierten Projekten und dem hohen Tempo ihrer Entwicklungskollegen abgehängt. Statt an bisherigen Vorgehensweisen festzuhalten, brauchen diese Teams für die Anwendungssicherheit neue Ansätze, um die hochmodernen Finanz-Apps ihres Unternehmens zu schützen.

Weitere Informationen dazu, wie dieser Wandel für Ihr Security-Team aussehen könnte, finden Sie in unserem Leitfaden zur Optimierung von AppSec im Finanzsektor.