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

Dans son habitat naturel, un développeur est souvent observé dans un état de profonde concentration, en train de coder des fonctionnalités impressionnantes dans des délais serrés. La création 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à dit, beaucoup d'entre nous continuent à donner la priorité aux fonctionnalités plutôt qu'aux meilleures pratiques en matière de sécurité. Après tout, dans la plupart des organisations, c'est le travail de quelqu'un d'autre et la formation adéquate en matière de sécurité est limitée. Les tests de pénétration et les outils d'analyse statique (mieux connus sous le nom de SAST) ne sont qu'une partie du processus global de réduction 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, bien sûr.

C'est à ce moment-là que de nombreux développeurs se disent: "Les pentesters me détestent-ils ?

Ces interactions définissent souvent une équipe, une culture. Le problème, c'est que le manque de communication, de compréhension et de collaboration générale 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 merveilleuse statue, et que quelqu'un arrive avec un marteau et commence à en briser 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 chouchous logiciels massacrés par une personne extérieure qui n'a pas travaillé avec lui tout au long du processus ; au lieu de cela, il a augmenté la charge de travail et retardé la satisfaction de la livraison du code.

Ayant évolué 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 détestent pas les développeurs. Le pentester est, selon toute vraisemblance, surchargé de travail et soumis à une forte pression. 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 l'espace de tête pour les problèmes vraiment sérieux.

J'ai toujours vu les pentesters comme des parents. Ils veulent que vous réussissiez, et quand vous ne réussissez pas... ils ne sont pas fâchés, juste déçus.

Maintenant que j'ai mis cette image (peut-être un peu injuste) dans votre esprit, explorons la question un peu plus en profondeur. Qu'est-ce qui est à l'origine de cette vision du monde chez les développeurs ?

"Bien sûr que 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 que quelqu'un n'aime pas son travail. Malheureusement pour les développeurs, lorsque les résultats de l'analyse statique et du pentest leur parviennent, ils peuvent avoir l'impression de recevoir un bulletin de notes. Ils ont reçu de mauvaises notes, mais en fin de compte, leurs patrons les évaluent sur les fonctionnalités qu'ils ont développées et le temps qu'ils ont mis pour les livrer, et non sur la présence ou non d'éléments vulnérables dans le logiciel.

Pour le pauvre pentester, c'est un cas de "ne pas tirer sur le messager". Il n'y a rien de personnel - ils sont chargés de trouver des bogues, et ils les ont trouvés. Certes, d'une personne à l'autre, certains pentesters 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 beaucoup plus facile pour les deux équipes d'être sur la même longueur d'onde en ce qui concerne les meilleures pratiques en matière de sécurité. On n'attend pas des développeurs qu'ils soient parfaits ; de manière réaliste, l'équipe de test est là pour les protéger contre l'envoi de code vulnérable.

"Ils m'ont dit de régler 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 résoudre s'ils s'en soucient tant ?"

C'est vrai : la priorité absolue d'un développeur sera toujours de créer des fonctionnalités et, dans ce monde fou de numérisation rapide, il devra le faire à toute vitesse. Si 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.

La plupart des vulnérabilités courantes sont en effet des problèmes mineurs à corriger - une fois connus, les correctifs sont simples à exécuter pour des choses comme le cross-site scripting (XSS) et l'injection SQL... le problème est que de nombreux développeurs ne réalisent pas qu'ils les introduisent en premier lieu, et ces problèmes apparemment mineurs sont la petite fenêtre d'opportunité dont un attaquant a besoin pour causer des problèmes dévastateurs pour une entreprise. Selon Akamai, entre novembre 2017 et mars 2019, les vulnérabilités d'injection SQL ont représenté 65 % de tous les vecteurs d'attaque basés sur le web. Pour une vulnérabilité dont la correction est connue depuis plus de vingt ans, c'est une statistique qui donne à réfléchir.

Certaines équipes de pentest aident à remédier aux bogues de sécurité, mais d'autres fourniront un rapport sur les mauvaises nouvelles et attendront des développeurs qu'ils travaillent sur les correctifs, même s'ils sont passés à un autre projet au moment où cela se produit. 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) corriger - cela doit toujours faire partie des conclusions et, encore une fois, ne pas être pris personnellement.

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 cycle de développement durable. 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 de bien meilleures connaissances en matière de sécurité qu'on ne le croit ; 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é dans le SDLC, et les outils d'analyse statique (SAST) jouent un rôle fondamental. Et oui, les faux positifs sont un problème avec ces outils et d'autres types de scanners (DAST/IAST/RAST). Il s'agit d'une gêne dans un processus déjà lent, qui nécessite un examen manuel du code et met la pression sur les développeurs comme sur les pentesters. Le personnel de pentesting 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, mais certaines lectures erronées se glissent et finissent devant un développeur qui se prend la tête.

Ce processus n'est pas parfait, mais l'autre problème est que de nombreux développeurs n'ont pas les connaissances suffisantes pour atténuer de manière cohérente un grand nombre de vulnérabilités courantes. La formation à la sécurité étant rare dans l'enseignement supérieur et la formation sur le tas plus ou moins efficace, il est logique qu'un certain excès de confiance soit également en jeu (et ce n'est pas de leur faute - en tant qu'industrie, nous devons mieux les équiper avec ce dont ils ont besoin).

"Je ne savais pas que cette application allait être testée, mais maintenant je suis coincé avec les tâches de remédiation".

Parfois, les ingénieurs surchargés de travail supposent que les pentesters sont juste dans les coulisses, attendant le moment de frapper en testant une application et en faisant pleuvoir sur la parade de l'équipe de développement. Ils font trop de tests, ils pinaillent, ils créent un surcroît de travail.

Le seul problème, c'est qu'ils sont eux aussi surchargés de travail (plus encore, en fait - la pénurie de compétences en cybersécurité atteint des niveaux catastrophiques et ne fait qu'empirer) et qu'ils n'ont tout simplement pas le temps de tester sans raison. Ils ne sont pas les seuls à décider de la priorité à accorder aux tests ; ceux-ci peuvent avoir été demandés par la direction, un client, dans le cadre d'un audit de sécurité ou même déterminés à la suite d'un programme de récompense des bogues.

Pour un développeur, il est ennuyeux d'être retiré des sprints de création de fonctionnalités 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 le problème de tous. Cela ne signifie pas que chaque développeur doive s'approprier les bogues de sécurité comme s'il les avait tous créés lui-même, mais il doit participer à la fête pour que la sécurité soit une responsabilité partagée.

Quelle est la suite des événements ?

Parfois, il suffit de changer d'état d'esprit pour progresser de manière significative 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 de pentest peu favorables, mais que se passerait-il s'il pouvait en faire un défi ? Peut-être pourraient-ils considérer le pentester comme un concurrent amical, quelqu'un qu'ils peuvent battre à leur propre jeu. Après tout, un développeur sensibilisé à la sécurité et capable d'éliminer les bogues courants au fur et à mesure qu'il écrit le code va rendre son travail beaucoup plus difficile. En revanche, un développeur qui ne se préoccupe pas de la sécurité sera largement battu par ses homologues pentesters lorsqu'ils parviendront facilement à casser leur logiciel.

Les pentesters et les développeurs ne sont peut-être pas toujours en harmonie, mais leurs relations peuvent être grandement améliorées lorsqu'une organisation fait de la sécurité une priorité essentielle et donne aux équipes les connaissances et les outils dont elles ont besoin pour réussir, en particulier aux développeurs. La question est de savoir si une culture de la sécurité positive à l'échelle de l'entreprise est une priorité, et si nous voulons mener la bataille (actuellement) perdue d'avance contre les vulnérabilités courantes, elle doit absolument l'être.