Instaurer la confiance : Le chemin vers une véritable synergie de sécurité entre AppSec et développeurs

Une version de cet article a été publiée dans Cyber Defense Magazine. Elle a été mise à jour et publiée ici.

Une relation bâtie sur les fondations chancelantes de la méfiance doit être abordée avec peu d'attentes. Malheureusement, c'est parfois le cas des relations de travail entre les développeurs et l'équipe AppSec d'une organisation. Généralement glaciale et entachée d'une tendance à se mettre des bâtons dans les roues, la situation n'est pas idéale et conduit à des résultats médiocres dans un monde de dépendances technologiques à haut risque.

Les développeurs s'épanouissent en résolvant des problèmes, en créant des fonctionnalités et en faisant preuve de créativité dans leur travail. L'AppSec, en revanche, a la tâche peu enviable de trouver des bogues de sécurité dans leur code, de les renvoyer pour qu'ils soient corrigés, et de fournir des audits et des rapports qui gâchent l'éclat des projets préférés des ingénieurs. Il n'est pas juste de rejeter la faute sur les seuls développeurs - la sécurité n'est pas leur priorité et ne fait pas partie de leurs indicateurs de performance - et l'équipe AppSec, surchargée de travail, ne peut pas non plus être pénalisée pour avoir simplement fait son travail. Cependant, pour les meilleures pratiques de cybersécurité et de meilleurs résultats en matière de sécurité au niveau de l'organisation, ils doivent vraiment commencer à jouer le jeu.

Et tout commence par la confiance.

L'image de "méchant" de l'AppSec fait obstacle à l'harmonie du DevSecOps.

Si vos seules interactions avec quelqu'un consistent à lui faire remarquer vos erreurs, il y a de fortes chances que sa contribution ne soit pas bien perçue.

Rarement vue en cas de problème, la présence de l'équipe de sécurité a des connotations négatives qui tendent à créer des frictions. Les relations sont rompues depuis un certain temps, les développeurs considérant l'équipe AppSec comme un obstacle à leur créativité, à leur processus et à la livraison ponctuelle de fonctionnalités, tandis que l'équipe AppSec se lasse de signaler continuellement des bogues de sécurité courants qui existent (tout comme leur remède) depuis des décennies.

Avec des délais de plus en plus serrés, des équipes manquant de ressources et un fort désir d'éviter les retouches, les développeurs attendaient souvent le dernier moment pour livrer leur code, réduisant ainsi au maximum la fenêtre d'opportunité pour l'examen et l'intervention de l'AppSec. Ce processus dysfonctionnel a pour conséquence inacceptable d'accroître les risques de cybersécurité pour l'entreprise.

Pour les spécialistes de la sécurité, il s'agit de "ne pas tirer sur le messager" - après tout, leur travail consiste à trouver des bogues et à les signaler pour qu'ils puissent être corrigés - rien de personnel. Le problème est qu'ils peuvent souvent faire des recommandations qui ne sont pas les mieux adaptées à la pile technologique de l'entreprise, et peuvent donc être considérés comme peu utiles dans le contexte plus large du développement de logiciels en interne.

La notion d'AppSec en tant que méchant est contre-intuitive pour la plupart des méthodologies de développement, mais pour DevSecOps, c'est un désastre. L'étalon-or est allé bien au-delà de Waterfall, Agile et même DevOps, dans un processus qui considère la sécurité comme une responsabilité partagée dès le début du SDLC comme vital.

Pour que DevSecOps fonctionne, il faut donner aux ingénieurs logiciels une raison de se préoccuper de la sécurité, et cela passe par la compréhension des raisons pour lesquelles il est si important pour eux de jouer leur rôle dans la sécurisation des logiciels du monde entier. Les spécialistes de la sécurité qui s'efforcent de tendre le rameau d'olivier, de travailler avec les responsables du développement pour répondre aux besoins de l'équipe et d'assumer un rôle de mentor en développant la sensibilisation à la sécurité ont tendance à tirer des avantages à long terme de leurs efforts... et à passer un peu moins de temps à s'arracher les cheveux à cause d'une énième erreur XSS.

Les développeurs doivent être en mesure d'obtenir de meilleurs résultats en matière de codage sécurisé.

Pour de nombreux ingénieurs, l'apprentissage du codage sécurisé au cours de l'enseignement supérieur est inexistant. Et ce n'est pas parce qu'ils étaient tous occupés à jouer au beer pong et à WoW - cela ne fait tout simplement pas partie de la plupart des diplômes en informatique.

C'est pourquoi la formation en cours d'emploi est souvent la première exposition d'un développeur à l'art de la sécurité des logiciels, et il est rare qu'elle mette le feu aux poudres. Des heures de vidéos ennuyeuses sont une méthode de formation courante, tout comme les exercices de conformité "à cocher" qui sont bien trop rares pour avoir un impact réel sur l'enseignement aux développeurs de la manière de coder en toute sécurité, ou pour faire des progrès dans la réduction des vulnérabilités courantes dans les logiciels d'une organisation.

L'équipe AppSec et la cohorte de développement sont toutes deux très occupées, c'est pourquoi toute formation doit être significative, engageante et pratique. En tant que développeurs, nous aimons résoudre les problèmes et utiliser les outils, et la plupart des formations statiques nous laissent de côté alors que nous nous concentrons sur quelque chose de plus urgent (ou, soyons honnêtes, de plus intéressant).

Les spécialistes de l'AppSec sont en position d'influence, et ils peuvent créer une situation gagnant-gagnant à long terme en défendant les intérêts des développeurs. La recherche d'une formation viable, adaptée à l'emploi et dispensée dans leurs langages et frameworks préférés, est un grand pas en avant pour faire bouger les choses et inspirer une culture de la sécurité positive au sein d'une organisation. Nous avons essayé la même chose pendant des décennies, et il est clair que l'approche de formation "taille unique" ne fonctionne pas. En aidant les développeurs à acquérir les bons outils et les bonnes connaissances, ils peuvent se perfectionner dans le codage sécurisé, agir avec un sens accru de la sécurité et produire un code de meilleure qualité.

Les efforts pour se mettre d'accord doivent venir des deux côtés.

Il est facile pour des personnes ayant des objectifs différents de ne pas se comprendre ou, dans le pire des cas, de se méfier les unes des autres. L'AppSec a pour objectif de suivre l'assaut du code qui est produit et de trouver tous les problèmes de sécurité qui peuvent conduire à la compromission des données, à l'accès non autorisé et aux attaques malveillantes qui ont le potentiel de détruire le sentiment positif des clients pendant des années.

Les développeurs, entre autres, construisent des fonctionnalités dans les délais impartis. Ils sont chargés de rendre les logiciels fonctionnels et esthétiques, et d'être les créateurs d'expériences numériques uniques qui fidélisent les clients. Ils ont déjà beaucoup à jongler, et leur lancer une balle courbe sous la forme d'une responsabilité en matière de sécurité est une perspective décourageante. On considère que le problème de l'AppSec est de sécuriser le code, et bien que cela ait été quelque peu réalisable dans les années 90 (vous savez, avant que nos voitures puissent être piratées et que nos vies entières puissent être transportées dans un superordinateur de poche appelé smartphone), il y a tout simplement trop de code et pas assez de personnes pour le faire passer par le gant de sécurité.

Avec une bonne dose d'empathie et la possibilité de faire de la sécurité une priorité dès le début du processus de création des logiciels, les responsables de la sécurité des applications et les développeurs peuvent trouver des moyens d'aligner leurs objectifs. Après tout, une culture positive de la sécurité en dépend, et les développeurs sensibilisés à la sécurité sont l'ingrédient secret pour stopper les vulnérabilités courantes, même avec une pénurie de compétences en cybersécurité qui ne cesse de s'aggraver.

Le respect mutuel du temps a d'immenses avantages.

Comme je l'ai déjà dit, tout le monde est très occupé lorsqu'il s'agit de faire de la magie (c'est-à-dire des logiciels extraordinaires). Les développeurs auront besoin de temps de travail pour suivre une formation pratique et viable qui leur permettra de renforcer leurs compétences en matière de codage sécurisé, et tout programme de formation devrait être hyperpertinent de par sa conception.

Les responsables de la sécurité des applications perdent leur temps en corrigeant sans cesse les mêmes vulnérabilités du Top 10 de l'OWASP, et les développeurs voient leur temps réduit par des exercices peu engageants qui renforcent l'idée dans leur esprit que la sécurité est une corvée.

Les expériences d'apprentissage curatif sont vitales et permettent d'aller à l'essentiel grâce à la fourniture contextuelle et par petites touches d'une formation pertinente, au moment où elle est nécessaire.

En organisant un cours de codage sécurisé sur mesure, adapté aux résultats souhaités et aux parcours d'apprentissage internes, on respecte le temps et le travail du développeur, tout en œuvrant à une réduction mesurable des vulnérabilités et des risques de cybersécurité pour l'entreprise. Il s'agit d'une victoire rapide dans la quête pour mettre fin aux douces rivalités et avancer dans le Far West de la cybersécurité en tant que front uni.

Secure Code Warriorest disponible dès maintenant, Coursesest disponible dès maintenant.

‍