Mon pentester, mon ennemi ? Les développeurs révèlent ce qu'ils pensent réellement des résultats des pentests et des analyses statiques

Dans son habitat naturel, un développeur est souvent aperçu dans un état de grande concentration, en train de coder des fonctionnalités géniales dans des délais serrés. La création de fonctionnalités est souvent notre partie préférée du travail, et c'est en fait le résultat fondamental du cycle de vie du développement logiciel (SDLC).

Cependant, comme nous l'avons déjà dit, beaucoup d'entre nous accordent toujours la priorité aux fonctionnalités par rapport aux meilleures pratiques de sécurité. Après tout, dans la plupart des organisations, cela est conçu pour être le travail de quelqu'un d'autre et la formation adéquate en matière de sécurité pour nous est limitée. Les tests d'intrusion et les outils d'analyse statique (mieux connus sous le nom de SAST) ne sont qu'une partie du processus global visant à atténuer les risques de sécurité, fonctionnant de manière assez indépendante de ce que nous faisons... jusqu'à ce que le code nous soit renvoyé pour les correctifs, bien sûr.

Et c'est à ce moment-là que de nombreux développeurs pensent : »Est-ce que les pentesters me détestent ? ».

Ces interactions définissent souvent une équipe, une culture. Ce qui est inquiétant, c'est que le manque de communication, de compréhension et de collaboration globale a créé des tensions, du moins du côté du développeur. Pensez-y : imaginez que vous avez passé quelques centaines d'heures à sculpter une statue merveilleuse, puis que quelqu'un arrive avec un marteau et commence à 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 logiciels préférés massacrés par un étranger qui n'a pas travaillé avec lui ; au lieu de cela, ils ont allongé la charge de travail et retardé la satisfaction du code d'expédition.

Ayant emménagé dans le domaine de la sécurité il y a longtemps, je peux voir les deux côtés de l'histoire. Et non, les pentesters ne le font pas haine développeurs. Selon toute probabilité, le pentester est surchargé de travail et soumis à de fortes pressions. En tant que tel, un flux constant de bogues de sécurité courants qui pourraient être facilement corrigés au niveau du code prend du temps, des ressources et de la marge de manœuvre par rapport aux problèmes vraiment graves.

J'ai toujours considéré les pentesters comme des parents. Ils veulent que tu réussis, et quand tu ne le fais pas... ils ne sont pas fâchés, juste déçus.

Maintenant que je vous ai donné cette image (peut-être un peu injuste), explorons-la un peu plus en profondeur. Qu'est-ce qui a provoqué cette vision du monde chez les développeurs ?

« Bien sûr, je suis sur la défensive ; ils me disent comment faire mon travail ! »

Personne n'aime avoir l'impression d'avoir fait du mauvais travail ou d'avoir l'impression que quelqu'un n'aime pas son travail. Malheureusement pour les développeurs, lorsque les résultats des analyses statiques et des pentests leur sont communiqués, cela peut ressembler à un bulletin. Ils ont reçu de mauvaises notes, mais en fin de compte, leur les chefs les évaluent en fonction des fonctionnalités qu'ils ont créées et du délai de livraison, et non de la présence d'éléments vulnérables dans le logiciel ou non.

Pour le pauvre pentester, il s'agit d'une question de « ne tirez pas sur le messager ». Cela n'a rien de personnel : ils sont chargés de trouver des bugs, et ils les ont trouvés. Certes, d'un point de vue personnel, certains pentesters sont peut-être plus grincheux que d'autres, mais ils ne sont pas (ou ne devraient pas) avoir pour but de crucifier les équipes de développement. Ce serait beaucoup plus facile pour les deux équipes si elles étaient sur la même longueur d'onde en ce qui concerne les meilleures pratiques en matière de sécurité. Et les développeurs ne sont pas censés être parfaits ; en réalité, l'équipe de test est là pour les empêcher de publier du code vulnérable.

« Ils m'ont demandé de régler tous ces problèmes mineurs. Ne savent-ils pas qu'il existe des priorités plus importantes ? Et pourquoi ne m'aident-ils pas à les réparer 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, il faudra le faire rapidement. Alors que certains codeurs 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 pentesters.

Les vulnérabilités les plus courantes sont en effet des problèmes mineurs à corriger. Une fois connus, les correctifs sont simples à exécuter pour des tâches telles que 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 en premier lieu, et ces problèmes apparemment mineurs constituent la petite fenêtre d'opportunité dont un attaquant a besoin pour provoquer des problèmes dévastateurs à une entreprise. Selon Akamai, entre novembre 2017 et mars 2019, les vulnérabilités liées à l'injection SQL ont été prises en compte 65 % de tous les vecteurs d'attaque Web. Pour une vulnérabilité qui a été corrigée depuis plus de vingt ans, c'est une statistique qui donne à réfléchir.

Certaines équipes de pentest aident à corriger les bogues de sécurité, mais d'autres signalent les mauvaises nouvelles et s'attendent à ce que les développeurs travaillent sur des correctifs, même s'ils sont passés à un autre projet au moment où cela se produit. Et dans certains cas, l'équipe de développement peut être confrontée à un rapport contenant des bogues qu'elle ne peut pas (ou ne devrait pas être censée) corriger. Cela doit tout de même faire partie des résultats et, encore une fois, ne pas être pris personnellement en compte.

Le « juste milieu » serait que les pentesters, le personnel de sécurité et les responsables du développement jouent davantage un rôle de mentor pour s'assurer que l'équipe dispose de ce dont elle a besoin en termes de formation et d'outils efficaces, donnant ainsi aux codeurs individuels les meilleures chances de réussir et de coder en toute sécurité dès le début du SDLC. 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 saine pratique DevSecOps.

« Mes connaissances en matière de sécurité sont bien meilleures que ce que l'on pense ; ces rapports sont pour la plupart des faux positifs ou ne sont pas importants ».

L'analyse statique est un élément du processus de sécurité du SDLC, 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 un inconvénient dans un processus déjà lent, qui nécessite une révision manuelle du code et met la pression sur les développeurs comme sur les pentesters. Le personnel de pentesting a mis du temps à mettre en place méticuleusement des règles personnalisées afin d'éviter des lectures inexactes et a fourni des conseils spécifiques à l'entreprise, mais certaines fausses lectures se glissent et se retrouvent devant un développeur époustouflant.

Ce processus n'est pas parfait, mais l'autre problème est que de nombreux développeurs ne disposent pas des connaissances suffisantes pour atténuer de manière cohérente de nombreuses vulnérabilités courantes. Étant donné que la formation à la sécurité est rare dans l'enseignement supérieur et que l'efficacité de la formation en cours d'emploi varie, il va de soi qu'il peut également y avoir un certain excès de confiance (et ce n'est pas de leur faute : en tant qu'industrie, nous devons mieux les équiper).

« Je ne savais pas que cette application allait être testée, mais je dois maintenant m'occuper des tâches de correction ».

Parfois, des ingénieurs surchargés de travail pensent que les pentesters ne font que rester dans les coulisses, attendant le moment venu pour tester une application et pleuvoir sur le défilé de l'équipe de développement. Ils font des tests excessifs, ils font des bêtises, ils créent du travail supplémentaire.

Le seul problème, c'est qu'ils sont eux aussi surchargés de travail (d'autant plus, en fait) que la pénurie de compétences en cybersécurité est à des niveaux désastreux et qui ne font qu'empirer) et vous n'avez tout simplement pas le temps de tester sans raison. Ils ne sont pas les seuls à décider de la priorité des tests ; ceux-ci peuvent avoir été demandés par la haute direction, par un client, dans le cadre d'un audit de sécurité ou même déterminés à la suite d'un programme de bug bounty.

Pour un développeur, il est ennuyeux de se voir retirer des sprints de création de fonctionnalités actuels pour travailler sur des correctifs de sécurité, surtout si ce n'est pas son travail. La dernière mise à jour a peut-être été effectuée par une équipe précédente ou par un autre fournisseur. Cependant, la sécurité est l'affaire de tous. Cela ne signifie pas que tous les développeurs doivent s'approprier les bogues de sécurité comme s'ils les avaient tous créés eux-mêmes, mais ils doivent faire en sorte que la sécurité soit une responsabilité partagée.

Où aller à partir d'ici ?

Parfois, un changement de mentalité peut suffire pour faire des progrès significatifs dans la résolution d'un problème. Nous avons parlé de la réaction plutôt glaciale d'un développeur face à des résultats moins que favorables aux pentests, mais que se passerait-il s'il pouvait en faire un défi ? Peut-être pourraient-ils considérer le pentester comme un adversaire amical, quelqu'un qu'ils peuvent battre à leur propre jeu. Après tout, un développeur soucieux de la sécurité capable d'éliminer les bogues courants en écrivant du code va rendre son travail encore plus difficile. En revanche, un développeur qui ne se concentre pas sur la sécurité sera largement battu par ses homologues pentester s'il peut facilement pirater son logiciel.

Les pentesters et les développeurs ne sont peut-être pas en harmonie dans tous les cas, mais leur relation peut être considérablement améliorée lorsqu'une organisation considère la sécurité comme une priorité essentielle et donne aux équipes les connaissances et les outils nécessaires pour réussir, en particulier les développeurs. Il s'agit de savoir si l'instauration d'une culture de sécurité positive à l'échelle de l'entreprise est une priorité, et si nous voulons mener la bataille (actuellement) perdue contre les vulnérabilités courantes, elle doit absolument l'être.