Est-il sûr d'utiliser du code source ouvert pour développer des applications Fintech ?

Le 13 avril 2023 - L'équipe de relations publiques de TuxCare

Post Views : 9

Les applications Fintech nécessitent un dispositif de sécurité particulièrement solide. Après tout, vous protégez les données financières (ou, plus déconcertant encore, l'argent) de vos clients.

Les prestataires de services financiers sont une cible lucrative pour les pirates informatiques et les attaques réussies comportent des risques importants pour les utilisateurs et les organisations qui possèdent et gèrent des applications fintech. Les développeurs de fintech doivent-ils donc utiliser du code open-source non commercial ?

C'est une question "ouverte" et, dans cet article, nous discuterons des risques - y compris ce que les développeurs fintech peuvent faire pour sécuriser le code open-source.

Des défis de taille en matière de sécurité pour le développement de logiciels Fintech

Les applications de la fintech sont soumises à des exigences de cybersécurité particulièrement strictes en raison des enjeux élevés qu'elles impliquent. Les risques et les défis courants en matière de cybersécurité dans la fintech comprennent les problèmes liés à l'informatique en nuage, les attaques de logiciels malveillants, l'accès par des tiers, la complexité et la compatibilité des systèmes, les risques de blanchiment d'argent, l'usurpation d'identité et l'authentification, et, surtout, la conformité.

Par exemple, pour garantir la sécurité des paiements électroniques, la directive sur les services de paiement (DSP2) est appliquée par de nombreuses juridictions - avec des réglementations spécifiques sur la sécurisation des données. Aux États-Unis, la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) est responsable de la réglementation de la collecte, du traitement et de l'utilisation des données pour les cartes de paiement - mais c'est une norme appliquée dans le monde entier.

Ainsi, les applications fintech ne sont pas seulement exposées à un risque de cyberattaque, mais aussi à un risque de non-conformité. Une faille de sécurité peut rapidement avoir de lourdes conséquences. Est-ce donc une bonne idée de s'appuyer sur du code "libre" ?

Qu'est-ce qui garantit la sécurité des données : code source ouvert ou code commercial ?

Il s'agit d'un débat brûlant et la bonne réponse n'est pas que le code commercial payant est plus sûr simplement parce que de l'argent est échangé en échange du code d'application.

Le code source ouvert est plus ouvert à l'examen car tout le monde peut l'examiner. En théorie, il est donc plus probable qu'un bogue dans un code open-source soit découvert. D'un autre côté, rien ne garantit que les bonnes personnes examinent d'un œil critique le code open-source ou que les développeurs sont motivés pour trouver des failles. En fait, il peut s'agir d'acteurs de la menace qui cherchent des failles.

Pourtant, les logiciels commerciaux à source fermée, motivés par le profit, ne sont pas nécessairement plus sûrs, car les vendeurs peuvent ne pas déployer de chercheurs en sécurité pour examiner le code à la recherche de failles et peuvent se hâter de coder pour respecter les délais.

En fin de compte, les développeurs commettent des erreurs, qu'ils soient rémunérés ou nonIl est donc important que les logiciels à code source ouvert et à code source fermé soient examinés et testés du point de vue de la sécurité. Pour les développeurs, cela signifie que les deux bases de code doivent être traitées avec la même prudence.

La sécurité des logiciels libres concerne tout le monde

Mais voici ce qui est intéressant : le code commercial s'appuie généralement sur des composants de code libre, de sorte que les organisations utilisent probablement du code libre dans leurs applications, même si elles s'appuient principalement sur des partenaires commerciaux.

Il s'agit essentiellement d'une prolifération de bibliothèques et de paquets de logiciels libres. Dans les applications basées sur l'informatique en nuage, plusieurs bibliothèques et services open-source sont généralement intégrés dans la pile technologique, ce qui permet aux développeurs de bénéficier du travail existant.

Cependant, dans certains cas, ils fournissent également aux attaquants une passerelle pour pénétrer dans les réseaux. Ces composants open-source peuvent contenir des vulnérabilités qui peuvent s'infiltrer dans la production, entraînant des retards dans le projet si elles sont identifiées tard dans le processus de construction ou après le déploiement.

Il s'agit d'une situation complexe avec des dépendances de dépendances qui constitue une menace distincte car il peut être facile de ne pas remarquer qu'une application invoque un paquet contenant des vulnérabilités. Quoi qu'il en soit, les vulnérabilités des logiciels libres font partie du processus de développement de la fintech, que les développeurs s'appuient principalement sur du code commercial ou du code libre.

Se concentrer sur DevSecOps pour assurer la sécurité

Le développement de logiciels modernes nécessite un processus de sécurité continu, et non une solution ponctuelle, et ce, que la base de code soit commerciale ou open source. Cette approche, connue sous le nom de DevSecOps, implique une responsabilité partagée de la sécurité entre les équipes de développement, de sécurité et d'exploitation.

La modélisation des menaces, les outils de test de sécurité, les tests de pénétration et les audits sont tous intégrés dans le pipeline CI/CD. Les développeurs peuvent également utiliser l'analyse de la composition des logiciels pour surveiller les composants open-source tout au long du processus de développement - et pour repérer les failles majeures connues qui rendent difficile la sécurisation des données. Cette approche collaborative permet une livraison plus rapide et plus sûre des applications fintech.

Tous les autres bons conseils sont, bien sûr, également valables : appliquer systématiquement les bonnes pratiques telles que l'AMF, les mots de passe forts, la gestion des informations d'identification et les autorisations strictes. La surveillance et les tests peuvent également permettre d'identifier les intrus et les failles. Comprenez les outils et les éléments sous-jacents dont vous dépendez, y compris les bibliothèques et les dépendances.

Le correctif est sans doute l'élément le plus crucial de la sécurité des logiciels. Des correctifs complets protègent contre les vulnérabilités connues, qu'il s'agisse de logiciels gratuits ou commerciaux. Mais la mise en place de correctifs cohérents est un défi et prend du temps, ce qui a souvent pour conséquence que seules les vulnérabilités les plus prioritaires sont prises en compte.

De plus, l'application de correctifs peut nécessiter un redémarrage ou une réinitialisation, et les équipes de développement peuvent retarder ou éviter l'application de correctifs pour maintenir la disponibilité. La solution du live patching mérite d'être envisagée.

Conclusion

La question n'est pas tant de savoir s'il est sûr d'utiliser du code source ouvert dans les applications fintech, ou non. Le code source ouvert est partout et se retrouvera probablement dans votre application fintech de toute façon. Devriez-vous utiliser un peu plus ou un peu moins de code source ouvert ? C'est une autre question, mais il n'est pas possible d'affirmer que le code source ouvert est intrinsèquement moins sûr.

Au lieu de cela, concentrez-vous sur la sécurisation de tout le code - y compris le code open-source que vous choisissez d'utiliser, et le code open-source qui se trouve de toute façon à l'intérieur de votre pile technologique.