5 raisons pour lesquelles les développeurs des institutions financières prennent de l’avance sur leurs équipes de sécurité

Biométrie avancée. Parcours d’intégration fluides. Intégrations multiplateformes. Tableaux de bord ultra-personnalisés. Rapports à la présentation soignée.

Voilà quelques-unes des fonctionnalités que les utilisateurs attendent aujourd’hui de leurs applications financières. Les institutions financières doivent donc les proposer rapidement, sous peine de se faire distancer par les acteurs disruptifs de la FinTech qui le font déjà. Les équipes de développement doivent ainsi accélérer la création de leurs produits et adopter de nouvelles technologies pour répondre à des objectifs ambitieux et à des délais serrés.

Cependant, alors que les développeurs des institutions financières adoptent rapidement de nouvelles technologies et méthodes pour suivre le rythme de l’innovation, leurs équipes de sécurité peinent souvent à suivre. Beaucoup tentent d’appliquer des technologies anciennes à de nouveaux environnements de développement, ce qui nuit involontairement aux résultats de l’entreprise.

Pourquoi les outils et processus éprouvés de sécurité des applications ne fonctionnent-ils pas pour ces équipes de sécurité ? Examinons quelques réalités des pipelines de développement actuels dans les services financiers pour le comprendre.

L’infrastructure as code (IaC) est gérée et provisionnée par les développeurs.

Comme de nombreuses entreprises hébergent aujourd’hui leur infrastructure dans le cloud à l’aide de l’IaC, plutôt que sur du matériel ou dans des centres de données, celle-ci relève désormais principalement de la responsabilité des équipes de développement. Les développeurs des institutions financières ne font pas exception. L’IaC est également vulnérable aux failles logicielles, un problème qui ne se posait pas lorsque les entreprises hébergeaient leur infrastructure sur site.

Les équipes de sécurité qui travaillent avec ces développeurs doivent donc inclure l’IaC dans leurs initiatives de sécurité des applications. Pourtant, de nombreuses technologies anciennes ne tiennent pas compte de l’IaC ni des vecteurs d’attaque qu’elle peut présenter.

Les applications sont hébergées dans des environnements multicloud complexes.

Au sein d’une grande institution financière, chaque équipe de développement utilise probablement un pipeline légèrement différent, avec diverses technologies et intégrations. Chaque pipeline est une machine bien huilée, conçue pour aller vite. En général, les développeurs effectuent toutes leurs tâches dans un environnement de développement intégré (IDE) dédié, ce qui leur permet de rester concentrés lorsqu’ils assemblent des logiciels.

Les équipes de sécurité chargées de sécuriser ces logiciels réagissent à cette situation où coexistent plusieurs pipelines de deux façons.

1. Elles tentent d’uniformiser les différents environnements technologiques en imposant à toutes les équipes de développement la même interface de sécurité. Cependant, cette démarche frustre souvent les développeurs, car elle les oblige à quitter leur état de concentration et à se connecter à une plateforme entièrement différente.

2. Elles adaptent manuellement leurs outils de sécurité pour les intégrer à chaque pipeline. Mais cette tâche peut vite devenir écrasante pour l’équipe de sécurité, qui doit la répéter pour chaque pipeline de développement de l’entreprise.

Souvent, les outils traditionnels ne laissent aux équipes de sécurité que ces deux options, car ils n’ont pas été conçus pour prendre facilement en charge la complexité et la diversité des workflows de développement dans le cloud.

L’architecture en microservices est monnaie courante.

L’architecture en microservices est également courante dans les pipelines de développement qui évoluent rapidement. Là encore, ces fonctionnalités aident les développeurs à accélérer leurs processus et à répondre à une forte demande des clients. Mais elles introduisent aussi des risques de sécurité supplémentaires, comme les vulnérabilités des images de conteneurs et les communications entre conteneurs aux autorisations trop larges.

Les outils de sécurité traditionnels passent souvent à côté de ces nouveaux types de vulnérabilités des conteneurs. Ils ne savent pas non plus distinguer ce qui est « normal » dans une architecture en microservices de ce qui révèle un problème de sécurité, ce qui génère des faux positifs et un trop grand nombre d’alertes.

L’automatisation joue un rôle essentiel dans le développement.

Les équipes de développement qui cherchent à suivre le rythme des acteurs disruptifs de la FinTech s’appuient aussi largement sur l’automatisation, notamment les outils CI/CD, pour fournir à grande échelle des fonctionnalités financières puissantes. Cette réalité a plusieurs conséquences pour les équipes de sécurité. D’abord, de nouveaux risques apparaissent : une faille dans une partie du pipeline CI/CD peut compromettre l’ensemble du processus. Ensuite, les outils de sécurité doivent suivre le rythme de ces étapes automatisées. Les outils manuels et les audits interminables ne sont pas adaptés à ces pipelines automatisés.

L’IA générative permet d’atteindre de nouveaux niveaux de rapidité.

Récemment, nous avons également constaté une accélération des pipelines de développement grâce aux assistants de programmation basés sur l’IA. La plupart des développeurs s’appuient largement sur ces assistants, auxquels ils confient souvent la production d’un code de qualité et sécurisé — même si ce n’est souvent pas le cas. Grâce à ces outils alimentés par l’IA, ils génèrent du code propriétaire bien plus rapidement que ne le permettraient des développeurs seuls.

Les outils traditionnels conçus pour sécuriser le code propriétaire écrit par des humains ne peuvent donc pas suivre le rythme. Ils ne sont pas conçus pour sécuriser les volumes considérables de code que les assistants de programmation basés sur l’IA peuvent générer.

De nouvelles pratiques de développement appellent de nouvelles approches de la sécurité

Sans les bons outils et processus, les équipes de sécurité des institutions financières se feront distancer par les projets ambitieux et les délais serrés de leurs collègues du développement. Plutôt que de s’en tenir aux méthodes établies, ces équipes de sécurité des applications doivent adopter de nouvelles approches pour protéger les applications financières de pointe de leur organisation.

Pour en savoir plus sur ce que cette évolution pourrait signifier pour votre équipe de sécurité, consultez notre guide pour optimiser la sécurité des applications dans le secteur des services financiers.