L’art de l’équilibre : 6 clés pour apaiser les tensions entre équipes sécurité et développement

Il existera toujours une tension naturelle entre les équipes de cybersécurité et les développeurs. Après tout, le rôle des développeurs est de « développer ». Ils veulent créer et déployer de nouvelles applications et fonctionnalités qui font avancer l’organisation, et sont rémunérés pour cela. Le rôle de la sécurité, en revanche, est de veiller à ce qu’aucun incident ne survienne lors du déploiement de nouveaux logiciels, par exemple une violation de données ou l’indisponibilité de services métier à cause de logiciels vulnérables.

Même si cette dynamique crée naturellement des tensions entre les deux fonctions, mon expérience m’a montré qu’il n’est pas nécessaire qu’il en soit ainsi. À condition de prendre les mesures adéquates pour favoriser la compréhension entre les deux groupes.

Malheureusement, beaucoup d’organisations ne prennent pas les mesures nécessaires. L’équipe de développement finit alors par considérer la sécurité comme un « obstacle » à surmonter. De leur côté, les équipes sécurité deviennent de plus en plus méfiantes envers les équipes de développement, qu’elles accusent de ne pas « prendre suffisamment la sécurité au sérieux ».

On a beaucoup écrit sur la façon d’améliorer les relations entre les développeurs et les équipes sécurité. Au cours de la dernière décennie, les pratiques DevOps se sont rapidement développées, avec pour objectif d’atténuer ces tensions. Elles ont rencontré un certain succès, mais pas suffisamment à mon avis. C’est pourquoi j’ai décidé de partager ce que j’ai appris en dirigeant l’équipe de sécurité applicative d’un grand opérateur télécom, où nous avons réussi dans une certaine mesure à apaiser les tensions entre développement et sécurité.

Chaque organisation est différente. Certaines équipes de développement et de sécurité travaillent principalement dans les locaux de l’entreprise, d’autres presque exclusivement à distance, et d’autres encore combinent les deux modes de travail. Certaines équipes comptent des spécialistes de la sécurité applicative très expérimentés, d’autres non. L’équipe dont je faisais partie travaillait principalement sur site. Ce qui a fonctionné pour nous ne fonctionnera peut-être pas pour tout le monde. Je suis néanmoins convaincu que les organisations qui appliqueront ces principes amélioreront les relations essentielles entre leurs équipes sécurité et développement.

Première clé : miser sur la formation.

Les organisations devraient proposer aux nouveaux développeurs une formation à la sécurité applicative, animée par l’équipe AppSec et par une personne ayant suffisamment d’expérience en développement pour gagner leur respect. Les spécialistes AppSec qui ont une expérience du développement comprennent les difficultés et les frustrations des développeurs lorsque les équipes sécurité communiquent de manière peu adaptée.

Cela vaut aussi, plus généralement, pour l’équipe AppSec. Lorsqu’elle est composée uniquement de spécialistes de la sécurité qui n’ont jamais travaillé dans le développement, des frictions risquent d’apparaître entre les deux groupes, car ils parleront probablement deux langages différents. Aucun ne comprendra les problèmes et les défis auxquels l’autre équipe est confrontée. En revanche, si l’équipe AppSec compte d’anciens développeurs, les relations entre les équipes seront tout autres.

Deuxième clé : en formation AppSec, utilisez des exemples concrets rencontrés par les équipes de développement et de sécurité en interne.

Dans toute formation AppSec, les formateurs expliquent comment des vulnérabilités peuvent être introduites dans le code, par exemple des failles par injection, le Cross-Site Scripting (XSS) ou des contrôles d’accès insuffisants. Ils décrivent également les conséquences de ces vulnérabilités pour la sécurité des applications et des données. Même si cette présentation est exacte, elle est aussi très monotone.

Pour rendre la formation plus vivante et capter l’attention, nous avons eu de bons résultats en y ajoutant des vulnérabilités applicatives découvertes par l’équipe sécurité lors de contrôles internes. Il ne s’agit pas de personnaliser la formation AppSec. Il ne faut surtout pas désigner des développeurs en particulier.

L’objectif est d’étudier ces problèmes ensemble. Il s’agit de montrer que les développeurs se concentrent sur la logique métier et le fonctionnement de l’application qu’ils créent, et non sur la sécurité. Parfois, la sécurité passe au second plan, et c’est compréhensible. Mais en présentant quelques exemples de vulnérabilités courantes détectées en interne et qui compromettent la sécurité de l’organisation, vous capterez leur attention et susciterez leur intérêt.

Troisième clé : dédramatiser la découverte de vulnérabilités.

Au début de notre présentation, nous avons montré une diapositive qui contribuait à dédramatiser la présence de vulnérabilités dans le code. Je ne révélerai pas le nom de la personne concernée, mais cette diapositive évoquait un professionnel de la sécurité bien connu. Il développe des logiciels de sécurité publiés en open source. Or, un logiciel qu’il avait créé et publié en open source comportait une vulnérabilité critique.

Si cette personne peut publier un logiciel comportant des vulnérabilités critiques, n’importe quel développeur peut commettre les mêmes erreurs. Cette diapositive montrait que la présence de défauts de sécurité dans le code est normale, même chez une personne très expérimentée en sécurité applicative. L’essentiel est de les détecter et de les corriger.

Quatrième clé : expliquer l’impact réel des vulnérabilités.

Nous ne nous sommes pas contentés de présenter les vulnérabilités découvertes en interne. Nous les avons aussi exploitées. Il faut montrer aux développeurs comment une vulnérabilité peut être exploitée et ce qu’un attaquant peut en faire.

Lors d’une des premières sessions de formation, un développeur a affirmé que les vulnérabilités XSS ne pouvaient pas être si dangereuses. Nous lui avons montré ce qu’un attaquant pouvait faire avec une attaque XSS : usurper l’identité d’une victime, accéder à des données sensibles, détourner une session, enregistrer les frappes au clavier, diffuser des logiciels malveillants, et bien plus encore.

Cette démonstration a été une véritable révélation. En fait, je pense que c’est un problème propre à l’AppSec. Lorsque les développeurs ne comprennent pas l’impact des vulnérabilités, ils ne sont pas motivés à les corriger ni à éviter qu’elles apparaissent dans leurs applications. Il est dans la nature humaine d’ignorer les risques dont on ne comprend pas les conséquences. C’est pourquoi montrer le risque réel peut avoir un tel impact. L’ajout de cette approche à notre formation a considérablement amélioré nos relations avec les développeurs.

Cinquième clé : les équipes sécurité doivent savoir ce qui est raisonnable.

J’ai constaté que les frictions entre ces deux équipes sont souvent dues à des demandes irréalistes de la part de l’équipe sécurité. Pendant la formation, il est essentiel d’apprendre à l’équipe de développement à collaborer au mieux avec l’équipe sécurité, c’est certain. Mais il est tout aussi important que l’équipe sécurité veille au caractère raisonnable de ses demandes.

Les demandes sont parfois déraisonnables parce que l’équipe sécurité exige de corriger des problèmes qui n’en sont pas. Cela arrive lorsqu’elle utilise un scanner de vulnérabilités applicatives qui signale une vulnérabilité inexistante ou ne présentant pas de risque réel. L’équipe sécurité transmet alors le résultat aux développeurs sans le vérifier, en leur demandant de le corriger. Si cela se répète, les développeurs finiront par se lasser et par ne plus vous écouter.

Les équipes sécurité doivent également avoir des attentes raisonnables, par exemple en accordant suffisamment de temps pour corriger les vulnérabilités, et davantage encore lorsqu’elles sont complexes.

Sixième clé : utiliser des outils fiables qui donnent les moyens d’agir aux développeurs.

Il est essentiel de choisir des outils d’analyse précis : ils expliquent clairement les problèmes détectés, leur attribuent un niveau de gravité adapté et indiquent comment corriger les vulnérabilités. Les développeurs peuvent ainsi comprendre comment résoudre les problèmes rencontrés. C’est encore mieux de leur fournir des outils conçus pour eux, afin qu’ils puissent travailler de manière autonome.

Même si les tensions entre les équipes sécurité et développement ne disparaîtront jamais complètement et que les organisations devront continuer à s’employer à les atténuer, nous avons constaté que quelques mesures simples favorisant la compréhension et l’empathie entre ces équipes contribuent grandement à améliorer leurs relations.

Rapprocher développeurs et équipes sécurité pour de meilleurs résultats avec la Snyk AI Trust Platform

Les six clés présentées ci-dessus sont des principes fondamentaux pour rapprocher les équipes de développement et de sécurité. Il ne s’agit pas de simples théories, mais de mesures concrètes qui favorisent l’empathie, créent une compréhension commune et instaurent un respect mutuel. Mais les principes ne suffisent pas. Ils doivent s’appuyer sur des outils qui permettent de les mettre en pratique. 

Lorsque vos outils sont conçus pour les développeurs, la séparation traditionnelle entre rapidité et sécurité disparaît. La sécurité cesse d’être un garde-fou et devient un partenaire de confiance au service de l’innovation. La Snyk AI Trust Platform offre ce terrain d’entente : les deux équipes peuvent parler le même langage et poursuivre le même objectif, à savoir livrer plus rapidement des logiciels sécurisés et de haute qualité.

La Snyk AI Trust Platform est conçue pour intégrer la sécurité de manière transparente au SDLC et s’attaquer directement aux causes profondes des frictions. Elle donne aux développeurs les moyens d’agir en leur fournissant des informations de sécurité rapides, précises et exploitables, là où ils travaillent : dans leur IDE, leur dépôt et leur pipeline CI/CD. 

Prêts à établir un véritable partenariat entre vos équipes de développement et de sécurité ? Réservez une démo en direct et découvrez comment donner à vos équipes les moyens d’intégrer la sécurité dès le départ.