Mon pentester, mon ennemi ? Les développeurs révèlent ce qu'ils pensent vraiment des tests d'intrusion et de l'analyse statique.

Un développeur dans son habitat naturel est souvent plongé dans une concentration intense, codant des fonctionnalités impressionnantes avec des délais serrés. Le développement de fonctionnalités est souvent notre partie préférée du travail et, en réalité, c'est le résultat fondamental du cycle de vie du développement logiciel (SDLC).

Cependant, comme nous l'avons déjà évoqué, beaucoup d'entre nous privilégient encore les fonctionnalités au détriment des bonnes pratiques de sécurité. Après tout, dans la plupart des organisations, c'est le travail de quelqu'un d'autre et notre formation en sécurité est limitée. Les tests d'intrusion et les outils d'analyse statique (plus connus sous le nom de SAST) ne sont qu'une partie du processus global d'atténuation des risques de sécurité, fonctionnant de manière assez indépendante de ce que nous faisons... jusqu'à ce que le code nous revienne pour des correctifs urgents, bien entendu.

Et c'est à ce moment-là que beaucoup de développeurs se disent : "Est-ce que les testeurs d'intrusion me détestent ?".

Ces interactions définissent souvent une équipe, une culture. Ce qui est préoccupant, c'est que le manque de communication, de compréhension et de collaboration globale a créé des tensions, du moins du côté des développeurs. Réfléchissez-y : imaginez que vous ayez passé quelques centaines d'heures à sculpter une statue magnifique, et que quelqu'un arrive avec un marteau pour en casser des morceaux après vous avoir dit que ses fondations ne sont pas à la hauteur. C'est la dynamique perçue entre un testeur et un développeur : ce dernier voit ses créations logicielles massacrées par un étranger qui n'a pas travaillé avec lui ; au lieu de cela, il a alourdi la charge de travail et retardé la satisfaction de livrer le code.

Ayant évolué dans le domaine de la sécurité depuis longtemps, je peux voir les deux côtés de l'histoire. Et non, les testeurs d'intrusion ne détestent pas les développeurs. Le testeur d'intrusion est très probablement surchargé de travail et soumis à une forte pression. Par conséquent, un flux constant de bugs de sécurité courants, qui pourraient être facilement corrigés au niveau du code, accapare du temps, des ressources et de l'énergie au détriment des problèmes vraiment sérieux.

J'ai toujours considéré les testeurs d'intrusion un peu comme des parents. Ils veulent que vous réussissiez, et quand ce n'est pas le cas... ils ne sont pas en colère, juste déçus.

Maintenant que j'ai planté cette image (peut-être légèrement injuste) dans votre esprit, explorons cela un peu plus en profondeur. Qu'est-ce qui a provoqué cette vision du monde chez les développeurs ?

"Bien sûr que je me défends ; ils me disent comment faire mon travail !"

Personne n'aime avoir l'impression d'avoir mal fait son travail ou que quelqu'un n'apprécie pas ce qu'il a produit. Malheureusement pour les développeurs, lorsque les résultats des analyses statiques et des tests d'intrusion leur reviennent, cela peut ressembler à un bulletin scolaire. Ils ont reçu de mauvaises notes, mais en fin de compte, leurs supérieurs les évaluent sur les fonctionnalités qu'ils ont créées et les délais de livraison, et non sur la présence ou non d'éléments vulnérables dans le logiciel.

Pour le pauvre testeur d'intrusion, c'est le cas typique du "ne tirez pas sur le messager". Ce n'est rien de personnel : ils ont pour mission de trouver des bugs, et ils les ont trouvés. Certes, au niveau interpersonnel, certains testeurs sont peut-être plus grincheux que d'autres, mais ils ne cherchent pas (ou ne devraient pas chercher) à crucifier les équipes de développement. Il serait bien plus facile pour les deux équipes d'être sur la même longueur d'onde concernant ce qui constitue les bonnes pratiques de sécurité. Et on ne s'attend pas à ce que les développeurs soient parfaits ; en réalité, l'équipe de test est là pour les protéger contre la livraison de code vulnérable.

"Ils m'ont dit de corriger tous ces problèmes mineurs, ne savent-ils pas qu'il y a des priorités plus importantes ? Et pourquoi ne m'aident-ils pas à les corriger s'ils s'en soucient tant ?"

C'est vrai : la priorité absolue d'un développeur sera toujours la création de fonctionnalités, et dans ce monde fou de numérisation rapide, cela doit être fait rapidement. Bien que certains développeurs s'intéressent personnellement à la sécurité et au codage sécurisé, le sentiment général est que la sécurité est "le problème de quelqu'un d'autre", ce qui inclut inévitablement les testeurs d'intrusion.

La plupart des vulnérabilités courantes sont effectivement des problèmes mineurs à corriger ; une fois identifiés, les correctifs sont simples à mettre en œuvre pour des failles comme le cross-site scripting (XSS) et l'injection SQL... le problème est que de nombreux développeurs ne se rendent pas compte qu'ils les introduisent, et ces problèmes apparemment mineurs sont la petite fenêtre d'opportunité dont un attaquant a besoin pour causer des dommages dévastateurs à une entreprise. Selon Akamai, entre novembre 2017 et mars 2019, les vulnérabilités par injection SQL représentaient 65 % de tous les vecteurs d'attaque basés sur le Web. Pour une vulnérabilité dont le correctif est connu depuis plus de vingt ans, c'est une statistique qui donne à réfléchir.

Certaines équipes de test d'intrusion aident à la remédiation des bugs de sécurité, mais d'autres se contentent de fournir un rapport de mauvaises nouvelles et attendent des développeurs qu'ils travaillent sur les correctifs, même s'ils sont passés à un autre projet entre-temps. Et dans certains cas, l'équipe de développement peut être confrontée à un rapport incluant des bugs qu'elle ne peut pas (ou ne devrait pas avoir à) corriger ; cela doit tout de même faire partie des conclusions, et encore une fois, ne pas être pris personnellement.

Le "juste milieu" serait que les testeurs d'intrusion, le personnel de sécurité et les responsables du développement agissent davantage comme des mentors pour garantir que l'équipe dispose de ce dont elle a besoin en termes de formation et d'outils efficaces, donnant ainsi aux développeurs individuels les meilleures chances de réussir et de coder de manière sécurisée dès le début du cycle de vie du développement logiciel. Les deux équipes devraient vraiment se rencontrer à mi-chemin pour s'assurer que la sécurité est prise en compte dès le départ, dans le cadre d'une pratique DevSecOps saine.

"J'ai une bien meilleure connaissance de la sécurité qu'on ne le pense ; ces rapports sont pour la plupart des faux positifs, ou sans importance."

L'analyse statique est un élément du processus de sécurité dans le cycle de vie du développement logiciel, et les outils d'analyse statique (SAST) jouent un rôle fondamental. Et oui, les faux positifs sont un problème avec ces types de scanners et d'autres (DAST/IAST/RAST). C'est une nuisance dans un processus déjà lent, nécessitant une revue manuelle du code et mettant la pression tant sur les développeurs que sur les testeurs d'intrusion. Le personnel chargé des tests d'intrusion a pris le temps de configurer méticuleusement des règles personnalisées pour éviter les lectures inexactes et a fourni des conseils spécifiques à l'entreprise, pourtant certaines fausses alertes passent à travers les mailles du filet et se retrouvent devant un développeur perplexe.

Ce processus n'est pas parfait, mais le problème est que beaucoup de développeurs manquent de connaissances pour atténuer efficacement les vulnérabilités courantes. La formation en sécurité étant rare dans l'enseignement supérieur et inégale en entreprise, un excès de confiance est inévitable (ce n'est pas leur faute : notre industrie doit mieux les outiller).

« Je ne savais pas que cette application allait être testée, et maintenant je me retrouve coincé avec les tâches de remédiation. »

Les ingénieurs, souvent surchargés, imaginent parfois que les pentesters attendent le moment opportun pour tester une application et gâcher leur travail. Ils pensent qu'ils testent à l'excès, cherchent la petite bête et créent du travail supplémentaire.

Le problème, c'est qu'ils sont eux aussi surchargés (la pénurie de compétences en cybersécurité est alarmante et ne fait qu'empirer) et n'ont tout simplement pas le temps de tester sans raison. Ils ne décident pas seuls des priorités ; ces tests peuvent être demandés par la direction, un client, un audit ou un programme de bug bounty.

Pour un développeur, être interrompu dans ses sprints pour corriger des failles de sécurité est frustrant, surtout si le code n'est pas le sien. Peut-être qu'une équipe précédente ou un prestataire s'en est chargé. Pourtant, la sécurité concerne tout le monde. Cela ne signifie pas que chaque développeur doit assumer la responsabilité de toutes les failles, mais il doit accepter que la sécurité est une responsabilité partagée.

Quelle est la suite ?

Parfois, un changement d'état d'esprit suffit à progresser. Nous avons évoqué la réaction froide des développeurs face aux résultats de tests d'intrusion, mais et s'ils voyaient cela comme un défi ? Ils pourraient considérer le pentester comme un concurrent amical à battre. Un développeur sensibilisé à la sécurité, capable d'éliminer les bugs dès l'écriture du code, rendra la tâche du pentester bien plus ardue.

Pentesters et développeurs ne seront peut-être jamais en parfaite harmonie, mais leur relation peut s'améliorer si l'organisation fait de la sécurité une priorité et donne aux équipes les moyens de réussir. Tout dépend de la volonté de l'entreprise d'instaurer une culture de sécurité positive, ce qui est indispensable pour gagner la bataille contre les vulnérabilités courantes.