DevSecOps : une démarche essentielle pour la fintech Algoan
En tant que fintech, Algoan considère qu’elle n’a pas le choix : elle se doit d’être « irréprochable » en matière de cybersécurité. Son CTO, Fabrice Ongenae détaille les outils et les mesures mis en place dans le cadre de son approche DevSecOps.
« Pour une jeune fintech, la sécurité est une raison de vie ou de mort », introduit Marine Vanier, responsable de la communication et marketing chez Algoan. « Si nous faisons une erreur de ce côté-là, cela peut nous coûter très cher sur le marché : nous nous devons d’être irréprochables vis-à-vis de nos clients ».
Fondée en 2018 à Paris, Algoan est une startup spécialisée dans l’aide à la décision à l’octroi de crédits.
« Algoan est une scale-up qui a pour objectif de rendre le crédit plus responsable et accessible », annonce Fabrice Ongenae, CTO d’Algoan.
« Les outils d’octroi de crédits n’ont pas tellement évolué ces dix dernières années. Avec l’essor du RGPD, mais surtout de la DSP2 et de l’open banking, il est possible d’avoir des outils beaucoup plus précis permettant d’éviter le surendettement et d’ouvrir le crédit à des gens qui gèrent très bien leur finance, mais qui selon les analyses classiques sont refusés », ajoute-t-il.
Les clients d’Algoan, ce sont une dizaine de banques, des organismes de crédits, d’autres fintech et des entreprises de leasing ou de crédits immobiliers dont Cofidis, Oney, Alma, ou encore Premista répartis entre la France, l’Allemagne, le Portugal, l’Espagne et la Belgique.
« En tant que prestataire de banques ou de compagnies financières et fournisseur d’un service très sensible, nous sommes attendus au tournant. Nous n’avons pas le droit à l’erreur », répète le CTO. « En matière de cybersécurité, les banques sont exigeantes et nous contrôlent régulièrement, tout comme nous voulons conserver la confiance des gens qui partagent leurs données bancaires ».
« En matière de cybersécurité, les banques sont exigeantes et nous contrôlent régulièrement ».
Fabrice OngenaeCTO, Algoan
Fabrice Ongenae a pu découvrir ces exigences au sein d’une autre fintech pour laquelle il travaillait précédemment. « J’ai suivi l’évolution de la philosophie DevOps qui s’est peu à peu ouverte à la sécurité. Au départ, il s’agit de faciliter, de ramener beaucoup d’agilité, d’interactions avec les différents services d’une entreprise plutôt que d’appliquer des recettes techniques ou d’associer les développeurs et les Ops », considère-t-il.
Embrasser la philosophie DevSecOps
Chez Algoan, qui entend proposer des services secure by design, l’approche DevSecOps s’est rapidement imposée.
« Nous appliquons le plus fidèlement possible la notion de DevSecOps qui revient à se poser la question suivante : à chaque étape d’un projet quels sont les actions ou les outils qui la sécurisent ? », résume le directeur technique. « Par exemple, avant même de développer une fonctionnalité, nous modélisons les risques avec OWASP Threat Dragon ».
« Pour autant, nous sommes encore une startup et il n’est pas question de perdre du temps : nous devons appliquer des mesures efficaces ». Et si le CTO et ses équipes ont d’abord utilisé des outils open source ou internes pour effectuer les différents tests, ils se sont tournés vers un éditeur du marché.
« Nous nous sommes rapidement rendu compte qu’il nous manquait un outil de SAST (Static application security testing) capable de véritablement détecter les vulnérabilités dans le cycle de vie de nos projets », indique Fabrice Ongenae. « En matière de vérification de licence, nous avions également besoin d’un outil. Il est possible de le faire manuellement au niveau 1 ou 2 d’une dépendance, mais au niveau -5, il faut automatiser cette tâche ».
Si plusieurs projets open source proposent ces fonctionnalités ensembles ou de manière séparée, Algoan s’est mis à sonder le marché en 2019. La startup a entre autres testé les solutions de Veracode, Snyk ou encore SourceClear pendant un mois chacune.
« Entre 2020 et 2021, nous avons mis en place les outils de Snyk parce qu’ils répondaient à nos exigences tant en matière de sécurité qu’en matière d’expérience développeur », affirme le CTO.
Les développeurs d’Algoan déploient VSCode, un IDE pour lequel Snyk propose un plug-in. « Aussi, Snyk s’intègre facilement à GitHub Actions que nous utilisons pour administrer nos pipelines CI/CD. Surtout, les retours de scans étaient plus qualitatifs. C’est toujours difficile à évaluer, mais nous avons observé plus de détections, un peu moins de faux positifs et une meilleure qualité de la documentation associée à la faille ou au bug notifié. Cela facilite le travail de nos développeurs quand il n’est pas possible de le faire via une mise à jour de dépendance ou autres ».
De l’importance de l’analyse des vulnérabilités
Ce choix s’inscrit dans une démarche « Shift Left », selon Fabrice Ongenae, considérant qu’il s’agit d’effectuer des tâches de vérification à la place des équipes de sécurité, généralement plus petites et occupées ailleurs.
Prosaïquement, Algoan a centralisé son activité de développement autour des Pull Requests issus de GitHub. « Nous avons inclus la revue de code par des pairs, les tests ; la documentation est mise automatiquement à jour dès qu’une fonctionnalité est poussée en production, nous avons aussi l’infrastructure as code, les retours de Snyk et l’analyse de la qualité du code avec Sonar Source », liste le CTO.
« Nous sommes en train d’ajouter des outils de pentests, OWASP ZAP, et sûrement d’autres solutions, et peut-être d’autres outils de détection. Nous voulons que ce soit le plus automatique possible et le plus simple possible pour les développeurs ». Dans les équipes, les développeurs utilisent Snyk dans l’IDE, tandis qu’un DevSecOps identifie les failles importantes et priorise les travaux de remédiation depuis le tableau de bord de l’outil. « De temps en temps, notre architecte peut s’assurer que tous les moyens sont en place ».
Si Fabrice Ongenae n’a pas véritablement d’historique pour comparer la période pré-Snyk, il a l’intuition que cela a amélioré l’activité de son équipe. « Auparavant, nous réalisions davantage de pentests manuels, exécutés par notre DevSecOps », souligne le CTO. « Comme toutes les tâches récurrentes et laborieuses sont automatisées, le gain de temps est important pour lui. Ces vérifications sont beaucoup plus intégrées auprès des développeurs et nous obtenons une vue macro, beaucoup plus exhaustive des choses qu’auparavant ».
Algoan n’utilise pas encore Snyk pour analyser le code IaC en production. « Ça ne va pas tarder, c’est prévu pour le premier trimestre 2022 », assure le directeur technique. « Les résultats que nous avons sur la préproduction et sur le staging sont très probants ».
L’équipe technique manipule différents outils pour analyser les dépendances et les images Docker, dont Snyk ou Google Container Registery Analysis, et finalise la mise en place de pentests et de tests de charge automatisés. « Cela nous a rendus suffisamment confiants pour ouvrir notre infrastructure à des plateformes de Bug Bounty, probablement dès le premier semestre 2022 ». Dans un même temps, Algoan compte obtenir la certification 27001.
Concernant la deuxième fonctionnalité de Snyk, la scale up compte approfondir son usage. « Nous allons probablement renforcer nos exigences sur la vérification des licences open source. Pour le moment, nous avons laissé les seuils par défaut », indique Fabrice Ongenae. « C’est important : aucune entreprise ne peut affirmer qu’elle n’est pas dépendante de l’open source ».
À la recherche d’un équilibre pour les développeurs
Si l’approche Shift Left est essentielle, il n’est pas question de délaisser les mesures de protection en production. Cela passe par le choix d’une infrastructure cloud que le CTO estime robuste, celle de Google Cloud Platform. « Quand je suis arrivé chez Algoan, nous étions chez Heroku parce que notre solution était encore en phase de PoC. C’est moi qui ai poussé pour aller sur Google Cloud et pour que l’on puisse profiter de leur WAF, de leur load balancer, et de toute l’infrastructure », affirme-t-il. « Il y a un coût derrière le cloud, ou le fait de faire appel à de grandes entités, mais on le récupère par des services qui sont souvent gratuits ou très peu chers. Le WAF de GCP est le même que celui de YouTube, le niveau de protection de base est déjà bon et il est possible d’ajouter des couches de sécurité supplémentaires ».
Algoan s’appuie également sur Google Security Command Center qui centralise les logs à la manière d’un SIEM et qui est connecté au WAF. « Nous avons d’autres outils pour détecter d’éventuelles modifications ou potentielles intrusions, dont Falco », complète le CTO.
« Il faut trouver l’équilibre entre liberté et sources de contrôle ».
Fabrice OngenaeCTO, Algoan
Mais au-delà des outils et des règles, quelle est la place du développeur chez Algoan ? « Nos développeurs sont passionnés, ils sont demandeurs. Ils veulent avoir plus d’impact dans la chaîne de valeur. Malgré les différents niveaux de sécurité et de contrôle, nous essayons de leur donner plus de liberté et de responsabilités », garantit Fabrice Ongenae. « Il s’agit aussi de favoriser le travail avec les équipes design et produit en amont, puis de concevoir la fonctionnalité attendue avec les bonnes mesures de sécurité et en discuter avec les Ops pour s’assurer que les bonnes métriques sont en place. C’est le développeur qui sera notifié le premier s’il faut effectuer des correctifs ou autres », explique-t-il. « Cela motive et permet de gagner en productivité. Il faut trouver l’équilibre entre liberté et sources de contrôle ».
Ce ne serait pas un problème au regard de la formation et de la bonne volonté des ingénieurs. Mais cette approche est également un moyen de garder les développeurs. « Tout le monde a des difficultés pour trouver des talents. Mais donner plus de responsabilités, être davantage à l’écoute et être plus attentionné permet de réduire le turn-over », affirme-t-il.
En dehors du fait de chercher à « recruter des passionnés », le directeur technique estime qu’il y a un autre « secret » pour favoriser l’adoption de l’approche DevSecOps. « Il ne faut pas demander aux développeurs de délivrer exactement à la même vitesse, alors qu’ils doivent effectuer plus d’actions pour obtenir un code sécurisé », souligne-t-il. « De notre côté, nous organisons des saisons de deux mois et demi composés de six sprints. En fonction de la dette technique et des analyses déjà effectuées, nous allouons 10 à 20 % du budget temps aux questions de sécurité. Il s’agit d’ajuster ce ratio pour ne pas surcharger le développeur ».
Éviter cette surcharge des développeurs permettrait d’éviter les pertes d’attention sur les aspects de sécurité. Cela veut aussi dire que les garde-fous doivent être en place. « Avec GitHub et Snyk, nous avons mis des blocages sur les éléments majeurs et critiques au moment de la pull request, qui obligent d’une certaine manière à corriger les défauts les plus importants. En revanche, le fait d’avoir des outils bien intégrés dans l’expérience développeur rend normalement la chose plus aisée », assure le CTO.
Log4j : Algoan s’en tire bien
Algoan a été très peu impactée par la faille d’Apache Log4j, qui risque d’occuper les équipes de sécurité des grands groupes pendant quelques mois. « Nous avons été très peu concernés par la faille. Nous avons une infrastructure basée sur NodeJS, Python et React, cela a grandement limité la chose », informe Fabrice Ongenae. « La version de Keyckloak que nous utilisons n’était pas faillible, seul notre plug-in Datadog était concerné par la vulnérabilité. Nous avons corrigé le jour même, au moment où Datadog nous a prévenus et c’était réglé. Comme notre infrastructure est hébergée sur Google Cloud, nous avons pu mettre en place la recommandation de Google pour bloquer ce genre d’attaques depuis le WAF de la plateforme ».
Il a fallu ensuite expliquer aux clients et aux partenaires que les sous-jacents techniques de la startup n’étaient pas ou plus soumis à la faille. « Nos clients nous ont demandé des rapports pour évaluer l’exposition à Log4Shell, mais j’avoue qu’ils ne nous ont pas communiqué si à l’inverse ils étaient concernés », déclare Fabrice Ongenae.
En cas de problème, Algoan sera informé, estime le CTO. « Nous avons de bonnes relations avec nos clients et leurs équipes de sécurité et nous sommes ouverts à la discussion ».
Si les différentes briques de la supply chain permettent d’identifier les vulnérabilités et de les corriger plus rapidement, le directeur technique est conscient qu’il faut prévoir toutes éventualités.
« De manière globale, dans une entreprise comme la nôtre, le point faible, ce sont les outils qui deviennent de plus en plus clé. Ils sont scrutés de très près par moi-même, notre DevSecOps, notre architecture et nos clients, afin de les sécuriser du mieux possible et éviter les éventuels impacts », explique Fabrice Ongenae. « En tant que startup, nous nous reposons en partie sur les éditeurs. Nous devons donc suivre l’écosystème pour recevoir les alertes le plus tôt possible, mais aussi multiplier les filets de protection afin d’accélérer la prise d’action et le blocage des attaquants ».
