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

Une version de cet article a été publiée dans Magazine de cyberdéfense. Il a été mis à jour et diffusé ici.

Il est préférable d'aborder une relation fondée sur les bases fragiles de la méfiance avec de faibles attentes. Malheureusement, il peut s'agir de l'état de la relation de travail entre les développeurs et l'équipe AppSec au sein d'une organisation. Généralement glaciale et marquée par une tendance à se gêner les uns les autres, la situation n'est pas idéale et donne de mauvais résultats dans un monde où la dépendance à la technologie est à haut risque.

Les développeurs s'épanouissent en résolvant des problèmes, en développant des fonctionnalités et en faisant preuve de créativité dans leur travail. AppSec, quant à elle, a la tâche peu enviable de trouver des bogues de sécurité dans son code, de le corriger pour les corriger 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é ni ne fait partie de leurs indicateurs de performance clés - et l'équipe AppSec, surchargée de travail, ne peut pas être pénalisée pour avoir simplement fait son travail. Cependant, pour bénéficier des meilleures pratiques en matière de cybersécurité et de meilleurs résultats en matière de sécurité au niveau organisationnel, ils doivent vraiment commencer à bien jouer.

Et tout commence par la confiance.

L'image de « méchant » d'AppSec fait obstacle à l'harmonie entre DevSecOps.

Si vos seules interactions avec quelqu'un ont lieu lorsqu'il vous indique où vous vous êtes trompé, il y a de fortes chances que sa contribution ne soit pas considérée favorablement.

Rarement observée sauf en cas de problème, la connotation négative de la présence de l'équipe de sécurité a tendance à provoquer des frictions. La relation est rompue depuis un certain temps, les développeurs considérant l'équipe AppSec comme un obstacle à leur créativité, à leurs processus et à la livraison ponctuelle de fonctionnalités, tandis qu'AppSec est très las de signaler continuellement les bogues de sécurité courants qui existent (tout comme leur remède) depuis des décennies.

Avec des délais de plus en plus impossibles, des équipes sous-financées et une forte volonté d'éviter les retouches, les développeurs attendaient souvent le dernier moment pour envoyer leur code, réduisant ainsi au maximum la fenêtre d'opportunité pour la révision et l'intervention d'AppSec. Un processus dysfonctionnel qui a pour effet inacceptable d'accroître le risque de cybersécurité pour l'organisation.

Pour les spécialistes de la sécurité, il s'agit de « ne pas tirer sur le messager ». Après tout, leur travail consiste à détecter les bogues et à les signaler afin qu'ils puissent être corrigés, rien de personnel. Le point d'achoppement est qu'ils peuvent souvent faire des recommandations qui ne sont pas les mieux adaptées à la technologie de l'entreprise, et qui peuvent donc être considérées comme peu utiles dans le cadre général du développement de logiciels internes.

L'idée qu'AppSec soit le méchant est contre-intuitive pour la plupart des méthodologies de développement, mais pour DevSecOps, c'est un désastre. La référence absolue est allée bien au-delà de Waterfall, Agile et même DevOps, pour adopter un processus qui considère la sécurité comme une responsabilité partagée dès le début du SDLC, un processus essentiel.

Pour que DevSecOps fonctionne, les ingénieurs logiciels doivent avoir une raison de se soucier de la sécurité, et cela passe par la compréhension de l'importance pour eux de contribuer à la sécurisation des logiciels du monde entier. Les spécialistes de la sécurité qui s'efforcent d'é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 dans la sensibilisation à la sécurité ont tendance à tirer des avantages à long terme de leurs efforts... et ils passent un peu moins de temps à s'arracher les cheveux à la suite d'une nouvelle erreur XSS.

Les développeurs doivent être en mesure de fournir de meilleurs résultats de codage sécurisés.

Lorsqu'il s'agit d'apprendre à coder de manière sécurisée pendant l'enseignement supérieur, pour de nombreux ingénieurs, c'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 et en informatique.

À cette fin, la formation en cours d'emploi est souvent la première occasion pour un développeur de découvrir l'art de la sécurité logicielle, et elle met rarement le feu à son univers. Des heures de vidéos ennuyeuses constituent une méthode de formation courante, tout comme les exercices de conformité « à cocher » qui sont bien trop rares pour avoir un réel impact sur l'apprentissage des développeurs sur la manière de coder en toute sécurité ou pour progresser dans la réduction des vulnérabilités courantes des logiciels d'une organisation.

L'équipe AppSec et la cohorte de développement sont toutes deux très occupées. Toute formation doit donc être significative, engageante et pratique. En tant que développeur, nous adorons résoudre les problèmes et utiliser les outils. C'est pourquoi la plupart des formations statiques ne nous permettent pas de nous concentrer sur des sujets plus urgents (ou, soyons honnêtes, intéressants).

Les spécialistes de la sécurité des applications sont influents et peuvent créer une situation gagnant-gagnant à long terme en défendant au mieux les intérêts des développeurs. La recherche d'une formation viable, adaptée à l'emploi et dispensée dans les langues et les cadres de leur choix constitue une étape importante pour changer les choses et inspirer une culture de sécurité positive et populaire au sein d'une organisation. Nous essayons la même chose depuis des décennies et, de toute évidence, l'approche de formation « universelle » ne fonctionne pas. En aidant à fournir les bons outils et les bonnes connaissances aux développeurs, ils peuvent améliorer leurs compétences en matière de codage sécurisé, agir avec un sens accru de la sécurité et produire un code de meilleure qualité.

Les efforts pour être sur la même longueur d'onde doivent venir des deux côtés.

Il est facile pour des personnes ayant des objectifs différents de mal se comprendre ou, au pire, de devenir quelque peu méfiantes. AppSec a pour objectif de suivre l'assaut du code généré et de détecter tout problème de sécurité susceptible d'entraîner la compromission des données, un accès non autorisé et des attaques malveillantes susceptibles de détruire la confiance des clients pendant des années.

Les développeurs, entre autres, créent des fonctionnalités dans les délais impartis. Ils ont pour mission de rendre les logiciels fonctionnels et esthétiques, et de créer des expériences numériques uniques qui fidélisent les clients. Ils ont déjà beaucoup de choses à gérer, et leur proposer une solution en matière de responsabilité en matière de sécurité est une perspective décourageante. La sécurisation du code est considérée comme le problème d'AppSec, et même si cela était quelque peu réalisable dans les années 90 (vous savez, avant nos voitures pourraient être piratées, et toute notre vie pourrait être transportée dans un superordinateur de poche appelé smartphone). Il y a tout simplement trop de code et pas assez de personnes pour le faire passer à travers le gantelet de sécurité.

Grâce à 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 logicielle, AppSec et les développeurs peuvent trouver des moyens d'aligner leurs objectifs. Après tout, une culture de sécurité positive 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 pénurie croissante de compétences en cybersécurité.

Le respect mutuel du temps présente 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 un logiciel incroyable) une réalité. Les développeurs auront besoin de temps de travail pour suivre une formation pratique et viable qui renforcera leurs compétences en matière de codage sécurisé, et tout programme de formation doit être hyperpertinent dès sa conception.

AppSec perd son temps à corriger le même problème Top 10 de l'OWASP les vulnérabilités à l'infini, et les développeurs sont confrontés à des exercices à faible engagement qui renforcent leur idée selon laquelle la sécurité est une corvée.

Les expériences d'apprentissage organisées sont essentielles et permettent d'aller droit au but prestation contextuelle et succincte d'une formation pertinente, juste au moment où cela est nécessaire.

En proposant un cours de codage sécurisé personnalisé, adapté aux résultats souhaités et aux parcours d'apprentissage internes, le temps et le flux de travail du développeur sont respectés, tout en s'efforçant de réduire de manière mesurable les vulnérabilités et les risques de cybersécurité pour l'entreprise. Il s'agit d'une victoire rapide dans la quête visant à mettre fin à de légères rivalités et à entrer dans le Far West de la cybersécurité en tant que front uni.

La dernière fonctionnalité d'apprentissage contextuel de Secure Code Warrior, Cours, est disponible dès maintenant.

‍