Cybersécurité dans la fintech : développer en toute sécurité avec l’open source

Pourquoi la cybersécurité est-elle importante pour les entreprises de la fintech ?

Les transactions financières constituent une cible naturelle pour les pirates informatiques en quête d’un gain facile. C’est pourquoi les banques traditionnelles sont soumises à des réglementations strictes en matière de cybersécurité. Les entreprises de technologie financière (fintech), en revanche, sont moins réglementées que les banques et omettent souvent des étapes essentielles du processus de sécurité, surtout lorsqu’aucune exigence claire ne les oblige à sécuriser pleinement leurs applications.

Les entreprises de la fintech devraient toutefois faire de la cybersécurité leur priorité absolue, et ce pour plusieurs raisons :

Types de données stockées

Comme les entreprises de la fintech traitent les mêmes types de données financières que les banques, elles attirent les cybercriminels. Ces données sensibles comprennent les informations sur les comptes et leurs soldes, les flux de trésorerie, les budgets et les coordonnées.

Compte tenu de la valeur de ces données, notamment pour l’exploration dans le cadre de projets d’IA/AA, les entreprises de la fintech ont tout intérêt à stocker le plus grand volume possible de données précises et utiles. Il y a toutefois un compromis à faire : le stockage de grandes quantités de données en fait des cibles plus intéressantes.

Coût des violations

Pour les banques traditionnelles, le coût d’une violation comprend les coûts directs et les coûts indirects, comme l’atteinte à la réputation et les amendes. Une seule violation peut aussi entraîner le départ de milliers de clients. Comme les entreprises de la fintech traitent le même type de données que les banques, une violation peut avoir des conséquences tout aussi négatives. La perte de confiance des clients et l’atteinte à la réputation peuvent être les aspects les plus coûteux d’une violation, en particulier pour les startups de la fintech ou les entreprises en hypercroissance. Les violations peuvent également entraîner des conséquences juridiques, sous forme d’amendes et de poursuites.

Conformité

Les entreprises de la fintech sont tenues de respecter les exigences Know Your Customer (KYC) ainsi que les réglementations locales de chaque région où se trouvent leurs clients. Ces réglementations comprennent :

• Pour l’UE : le Règlement général sur la protection des données (RGPD) encadre le traitement des données personnelles des personnes résidant dans l’UE, même si l’organisation se trouve hors de l’UE. Le règlement sur l’identification électronique et les services de confiance (eIDAS) régit les transactions numériques transfrontalières et fournit un cadre unifié aux entreprises de la fintech, aux organisations clientes, aux autorités réglementaires et aux utilisateurs finaux. La directive sur les services de paiement (DSP2) définit les exigences de sécurité relatives aux paiements électroniques. La DSP2 recoupe souvent le RGPD ; il peut donc être nécessaire de consulter des spécialistes pour garantir la conformité.

• Pour les États-Unis : la norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS), qui régit la collecte, le traitement et l’utilisation des données des principales cartes de crédit.

• Pour l’État de Californie : la loi californienne sur la protection de la vie privée des consommateurs (CCPA) ressemble au RGPD, mais s’en distingue sur certains points, notamment dans la définition de termes juridiques. Yodlee, un agrégateur de données financières, a fait l’objet d’un recours collectif après avoir prétendument enfreint la CCPA par ses pratiques de collecte et d’utilisation des données.

Quels défis les entreprises de la fintech rencontrent-elles en matière de cybersécurité ?

La cybersécurité doit être une priorité absolue pour les entreprises de la fintech, mais de nombreux obstacles les empêchent de sécuriser correctement leurs applications. Traditionnellement, la cybersécurité visait à protéger le produit final à l’aide de mots de passe, du chiffrement, de l’authentification multifacteur et d’une logique sécurisée. La responsabilité de la sécurité incombait aux équipes informatiques et de sécurité. Les applications étaient principalement testées après leur mise en production, ce qui exposait de nombreuses organisations. Lorsqu’un bogue ou une vulnérabilité était découvert, les équipes de sécurité devaient remonter jusqu’aux équipes de développement.

Aujourd’hui, la plupart des entreprises intègrent aussi des tests de sécurité avant la mise en production. Le problème, c’est que les résultats imprévus peuvent allonger le cycle de publication. Comment gérer des dizaines, voire des centaines de vulnérabilités découvertes ? Leur correction peut nécessiter d’importantes réécritures des composants logiciels sous-jacents, qui devront ensuite être vérifiés et testés à nouveau. De plus, cela crée des tensions entre les équipes de sécurité et de développement. Les développeurs peuvent livrer des logiciels non sécurisés pour commercialiser plus vite un produit fintech, mais corriger les problèmes plus tard dans le cycle de développement logiciel (SDLC) coûte très cher.

En bref, ces pratiques de test traditionnelles sont devenues obsolètes. Les types de vulnérabilités ont évolué, tout comme les méthodes de développement et de livraison des logiciels. Face aux exigences du marché, qui impose des livraisons rapides, le développement d’applications s’appuie désormais sur une approche agile. Cette approche DevOps plus moderne consiste à remplacer les grandes versions monolithiques par des sprints plus courts, à publier de nouvelles fonctionnalités plusieurs fois par jour, à accélérer les itérations et à automatiser autant que possible. Les organisations qui adoptent une approche agile constatent que les outils de sécurité des applications hérités, conçus avant l’ère du cloud, freinent les déploiements rapides et sécurisés.

Quels sont les risques de l’open source pour les entreprises de la fintech ?

La prolifération des bibliothèques et packages open source pose un défi supplémentaire à la cybersécurité dans la fintech. Les applications cloud intègrent généralement de nombreuses bibliothèques et services open source. Les développeurs peuvent ainsi tirer parti du travail déjà réalisé par d’autres, mais cela ouvre aussi une brèche que les attaquants peuvent exploiter pour pénétrer les réseaux.

Ces applications open source peuvent comporter des vulnérabilités qui se retrouvent en production. Lorsqu’elles sont détectées à la fin du processus de build ou en production, elles finissent par retarder les projets.

Les dépendances transitives (ou dépendances des dépendances) présentent un risque particulier, car elles forment un arbre de dépendances complexe. Il est alors facile de ne pas remarquer qu’une application fait appel à un package vulnérable. À mesure que l’utilisation de l’open source augmente, les applications fintech modernes présentent une surface d’attaque qui ne se limite plus au code propriétaire qu’elles développent.

Comment instaurer une culture DevSecOps dans la fintech ?

Dans le contexte du développement logiciel moderne, la sécurité doit être un processus et non une solution ponctuelle. Elle doit être intégrée tout au long du cycle de développement, à l’aide d’outils de test de sécurité, de tests d’intrusion et d’audits.

Cette nouvelle approche de la sécurité, appelée DevSecOps, prolonge DevOps en instaurant une responsabilité partagée en matière de sécurité entre les équipes de développement, de sécurité et d’exploitation. Dès le début, les équipes de sécurité et DevOps collaborent pour intégrer la sécurité au pipeline CI/CD. La modélisation des menaces intervient tôt et régulièrement. Tout au long du processus, les développeurs utilisent l’analyse de la composition logicielle (logicielle composition analysis (SCA)) pour surveiller les composants open source.

Les fonctionnalités et applications en production sont le fruit d’un travail collaboratif. L’équipe de sécurité n’a plus besoin d’intervenir après coup auprès des équipes de développement, qui savent que la sécurité a été intégrée au processus dès le départ. Intégrer la sécurité aux processus DevOps permet ainsi aux développeurs de se l’approprier. Comme les vulnérabilités et les bogues sont détectés tôt, DevSecOps permet au final de livrer des logiciels plus rapidement et de façon plus sécurisée, tout en réduisant les coûts.

La transition de DevOps vers DevSecOps ne relève pas de la seule responsabilité des développeurs. Les équipes de sécurité doivent superviser la planification et veiller à intégrer la sécurité en perturbant le moins possible les workflows existants.

Adopter une approche secure by design

DevSecOps vise à intégrer la sécurité dès la conception des logiciels. Cette démarche commence dès les premières étapes du développement avec la sécurité logicielle, une approche proactive qui vise à prévenir les problèmes de code tels que les dépassements de tampon et la mauvaise gestion des exceptions.

Il est essentiel de bien maîtriser ces premières étapes du développement en mettant en place des outils et des procédures pour détecter et corriger les bogues. Les chaînes de dépendances des bibliothèques et packages open source constituent un autre point clé : elles peuvent devenir complexes et masquer les vulnérabilités des applications.

Des boucles de rétroaction rapides contribuent à réduire le nombre de bogues. Il est également important de choisir les bibliothèques open source selon les principes du secure by design.

Appliquer les principes du shift left

La sécurité shift left est un aspect essentiel du secure by design : elle intègre les mesures de sécurité des applications dès le départ. Le shift left permet aux développeurs d’intégrer la sécurité à leurs workflows existants, tandis que les équipes de sécurité les accompagnent et assurent la supervision. La démarche commence par la définition de politiques de sécurité, puis par l’évaluation du processus de création logicielle pour repérer les petites améliorations qui permettront de tester plus tôt. Il est essentiel d’automatiser la sécurité et de donner aux équipes une visibilité constante sur le processus.

Mettre en place un SDLC sécurisé

Un SDLC sécurisé complète une approche DevSecOps du développement logiciel. DevSecOps vise à partager la responsabilité de la sécurité des applications, tandis qu’un SDLC sécurisé consiste à intégrer la sécurité au processus de conception et de développement.

La sécurisation du SDLC standard commence par un changement d’état d’esprit au sein des équipes de développement. L’objectif ne doit pas être uniquement la fonctionnalité, mais aussi la sécurité à chaque étape du projet. Il ne s’agit pas de supprimer les vérifications traditionnelles, mais de traiter les problèmes potentiels dès le départ plutôt que de devoir revenir en arrière une fois le logiciel mis en production.

Les équipes de développement pilotent les efforts de sécurité : ce sont les experts du domaine qui écrivent le logiciel qui corrigent les problèmes. Cela peut sembler représenter beaucoup de travail, mais la majeure partie est automatisée dans un environnement SDLC sécurisé. Résultat : des applications plus sécurisées en production, à moindre coût.

Comment Snyk accompagne la cybersécurité dans la fintech

Snyk Open Source est un outil SCA qui détecte les vulnérabilités des dépendances pendant que vous codez dans votre IDE ou votre CLI. Conçu pour les développeurs, il analyse les pull requests avant leur fusion et peut bloquer les vulnérabilités avant qu’elles ne passent l’étape du build. Snyk permet d’automatiser les tests tout au long de votre pipeline CI/CD et teste en continu vos applications pour détecter leur exposition aux vulnérabilités connues ou récemment découvertes. Parmi ses autres fonctionnalités : la surveillance continue, des règles de sécurité personnalisées et la gestion automatisée de la conformité des licences.

En tant qu’entreprise de la fintech qui traite des informations sensibles et privées, Revolut doit respecter des normes spécifiques. La mise en œuvre de Snyk permet à l’entreprise de protéger son infrastructure centrale et de maintenir sa conformité PCI, entre autres.

« Nous sommes audités toute l’année. Avec Snyk, nous pouvons affirmer que notre pipeline open source est sécurisé », explique Evangelos Deirmentzoglou. « Il ne s’agit donc pas seulement d’améliorer notre niveau de sécurité, mais aussi de soutenir nos efforts de conformité. »

Découvrez comment Revolut a utilisé Snyk pour améliorer sa cybersécurité et respecter les normes réglementaires.

Pour en savoir plus sur l’utilisation des composants open source dans la fintech, regardez notre webinaire à la demande : Bonnes pratiques et pièges à éviter dans l’utilisation des composants open source dans la fintech

FAQ sur la cybersécurité dans la fintech