Ist es sicher, Open-Source-Code für die Entwicklung von Fintech-Anwendungen zu verwenden?

April 13, 2023 - TuxCare PR Team

Fintech-Anwendungen erfordern eine besonders starke Sicherheitsvorkehrung. Schließlich schützen Sie die Finanzdaten (oder, noch beunruhigender, das Geld) Ihrer Kunden.

Finanzdienstleister sind ein lukratives Ziel für Hacker, und erfolgreiche Angriffe bergen große Risiken für die Nutzer und die Organisationen, die Fintech-Anwendungen besitzen und betreiben. Sollten Fintech-Entwickler daher nicht-kommerziellen, quelloffenen Code verwenden?

Es ist eine "offene" Frage, und in diesem Artikel werden wir die Risiken erörtern - einschließlich der Frage, was Fintech-Entwickler tun können, um Open-Source-Code zu sichern.

Schwierige Sicherheitsherausforderungen für die Entwicklung von Fintech-Software

Für Fintech-Anwendungen gelten besonders hohe Anforderungen an die Cybersicherheit, da hier viel auf dem Spiel steht. Zu den üblichen Cybersecurity-Risiken und -Herausforderungen in der FinTech-Branche gehören Cloud-Computing-Probleme, Malware-Angriffe, der Zugriff durch Dritte, Systemkomplexität und -kompatibilität, Geldwäscherisiken, Identitätsdiebstahl und -authentifizierung sowie - ganz wichtig - die Einhaltung von Vorschriften.

Um die Sicherheit im elektronischen Zahlungsverkehr zu gewährleisten, wird beispielsweise die Zahlungsdiensterichtlinie (PSD2) in vielen Ländern durchgesetzt - mit spezifischen Vorschriften zur Datensicherheit. In den USA ist der Payment Card Industry Data Security Standard (PCI DSS) für die Regulierung der Erfassung, Verarbeitung und Nutzung von Daten für Zahlungskarten zuständig - aber es ist ein Standard, der überall auf der Welt gilt.

Fintech-Anwendungen sind also nicht nur dem Risiko von Cyberangriffen ausgesetzt, sondern auch der Gefahr der Nichteinhaltung von Vorschriften. Eine Sicherheitslücke kann schnell große Folgen haben. Ist es daher eine gute Idee, sich auf "freien" Code zu verlassen?

Was hält Daten sicher: Open Source oder kommerzieller Code?

Es ist eine heiße Debatte, und die richtige Antwort lautet nicht, dass bezahlter, kommerzieller Code sicherer ist, nur weil für den Anwendungscode Geld gezahlt wird.

Open-Source-Code ist offener für Überprüfungen weil jeder ihn sich ansehen kann. Theoretisch ist es also wahrscheinlicher, dass ein Fehler in quelloffenem Code entdeckt wird. Andererseits gibt es keine Garantie dafür, dass sich die richtigen Leute kritisch mit Open-Source-Code auseinandersetzen oder dass die Entwickler motiviert sind, Fehler zu finden. Es könnten sogar Bedrohungsakteure sein, die nach Fehlern suchen.

Kommerzielle Software mit geschlossenem Quellcode, die auf Profit ausgerichtet ist, ist jedoch nicht unbedingt sicherer, da die Anbieter möglicherweise keine Sicherheitsforscher einsetzen, um den Code auf Schwachstellen zu untersuchen, und die Codierung überstürzen, um die Fristen einzuhalten.

Letztendlich, Entwickler Fehler machen, unabhängig davon, ob sie bezahlt werden oder nichtund es ist wichtig, dass sowohl Open-Source- als auch Closed-Source-Software auf ihre Sicherheit hin überprüft und getestet wird. Für die Entwickler bedeutet das, dass beide Code-Basen mit der gleichen Vorsicht behandelt werden müssen.

Die Sicherheit von Open Source geht jeden etwas an

Aber jetzt kommt der interessante Teil: Kommerzieller Code stützt sich häufig auf Open-Source-Code-Komponenten, so dass Unternehmen wahrscheinlich Open-Source-Code in ihren Anwendungen verwenden, selbst wenn sie sich hauptsächlich auf kommerzielle Partner verlassen.

Im Grunde genommen gibt es eine Vielzahl von Open-Source-Bibliotheken und -Paketen. Bei Cloud-basierten Anwendungen werden in der Regel mehrere Open-Source-Bibliotheken und -Dienste in den Tech-Stack integriert, sodass die Entwickler von der vorhandenen Arbeit profitieren können.

In einigen Fällen bieten sie Angreifern jedoch auch ein Einfallstor, um in Netzwerke einzudringen. Diese Open-Source-Komponenten können Schwachstellen enthalten, die in die Produktion eindringen und zu Projektverzögerungen führen können, wenn sie erst spät im Build-Prozess oder nach der Bereitstellung entdeckt werden.

Es ist eine komplizierte Situation mit Abhängigkeiten von Abhängigkeiten, die eine eindeutige Bedrohung darstellt, da es leicht zu übersehen ist, wenn eine Anwendung ein Paket aufruft, das Sicherheitslücken enthält. So oder so sind Open-Source-Schwachstellen Teil des Fintech-Entwicklungsprozesses, unabhängig davon, ob die Entwickler hauptsächlich auf kommerziellen Code oder auf Open-Source-Code zurückgreifen.

Konzentration auf DevSecOps für mehr Sicherheit

Die moderne Softwareentwicklung erfordert einen kontinuierlichen Sicherheitsprozess, keine einmalige Lösung, und es spielt keine Rolle, ob es sich um eine kommerzielle oder eine Open-Source-Codebasis handelt. Dieser Ansatz, bekannt als DevSecOps, beinhaltet die gemeinsame Verantwortung für die Sicherheit zwischen Entwicklungs-, Sicherheits- und Betriebsteams.

Bedrohungsmodellierung, Sicherheitstest-Tools, Penetrationstests und Audits sind in die CI/CD-Pipeline integriert. Entwickler können auch die Softwarekompositionsanalyse nutzen, um Open-Source-Komponenten während des gesamten Entwicklungsprozesses zu überwachen - und um auf bekannte große Schwachstellen zu achten, die es schwer machen, Daten sicher zu halten. Dieser kollaborative Ansatz führt zu einer schnelleren und sichereren Softwarebereitstellung für Fintech-Anwendungen.

Alle anderen guten Ratschläge sind natürlich auch gültig: Wenden Sie konsequent gute Praktiken wie MFA, sichere Passwörter, Verwaltung von Anmeldeinformationen und strenge Berechtigungen an. Überwachung und Tests können auch Eindringlinge und Schwachstellen identifizieren. Verstehen Sie die Tools und die zugrunde liegenden Bausteine, auf die Sie angewiesen sind, einschließlich Bibliotheken und Abhängigkeiten.

Das wohl wichtigste Element der Softwaresicherheit ist das Patchen. Umfassendes Patching schützt vor bekannten Schwachstellen, unabhängig davon, ob es sich um kostenlose oder kommerzielle Software handelt. Ein konsequentes Patching ist jedoch schwierig und zeitaufwändig und führt oft dazu, dass nur die Schwachstellen mit der höchsten Priorität behoben werden.

Außerdem kann das Patchen einen Neustart oder Reboot erfordern, und die Entwicklungsteams können das Patchen verzögern oder vermeiden, um die Verfügbarkeit aufrechtzuerhalten. Live-Patching ist als Lösung eine Überlegung wert.

Schlussfolgerung

Die Frage ist nicht so sehr, ob es sicher ist, Open-Source-Code in Fintech-Anwendungen zu verwenden, oder nicht. Open-Source-Code ist überall und wird wahrscheinlich sowieso seinen Weg in Ihre Fintech-Anwendung finden. Sollten Sie etwas mehr oder etwas weniger Open-Source-Code verwenden? Das ist eine andere Frage - aber man kann nicht wirklich ein Argument konstruieren, dass Open-Source-Code von Natur aus weniger sicher ist.

Konzentrieren Sie sich stattdessen auf die Sicherung des gesamten Codes - einschließlich des Open-Source-Codes, den Sie verwenden möchten, und des Open-Source-Codes, der sich ohnehin in Ihrem Tech-Stack befindet.