Gérer la responsabilité en matière de sécurité à grande échelle : le point de vue de Twilio

À mesure que les organisations adoptent les pratiques DevSecOps pour livrer des logiciels sécurisés, la responsabilité en matière de sécurité devient un enjeu toujours plus crucial. Snyk a récemment organisé une table ronde avec Twilio pour discuter de cette responsabilité en 2021.

Dans cet article, nous revenons sur la discussion entre Guy Podjarny, président et cofondateur de Snyk, et Yashvier Kosaraju, responsable senior de la sécurité produit chez Twilio. Les équipes Product Security de Twilio utilisent Snyk Open Source pour garantir la sécurité du code à toutes les étapes, de la conception au déploiement.

Comment décider qui (développement ou sécurité) est responsable de quoi

Lorsqu’une entreprise adopte une approche DevSecOps, elle doit répondre à une question essentielle : que doivent prendre en charge les équipes de développement et de sécurité en matière de pratiques et de processus ?

Les équipes de sécurité doivent prendre en charge toutes les fonctions de sécurité, comme les analyses, la modélisation des menaces et les tests d’intrusion, ainsi que les processus liés au cycle de développement logiciel sécurisé (SSDLC) et à la sécurité de l’entreprise. De leur côté, les équipes de développement doivent gérer les risques et veiller à corriger les vulnérabilités dans les meilleurs délais.

Cela dit, Kosaraju estime que l’équipe de sécurité doit fournir des outils faciles à utiliser afin de faciliter l’obtention de résultats.

« Quand vous recrutez des développeurs, vous cherchez à savoir s’ils savent coder, concevoir et s’ils maîtrisent les algorithmes, explique Kosaraju. Ce n’est pas un reproche, mais l’expertise en sécurité est rarement une priorité lors du recrutement. Il est donc essentiel de disposer d’une équipe dédiée à la sécurité, qui prend ces décisions pour votre entreprise. » 

En définitive, il revient aux équipes de direction de décider qui est responsable de quoi. Mais l’équipe de sécurité doit servir de « centre d’excellence » pour les développeurs, car les pratiques et les contrôles devront être intégrés directement aux applications.

Il est également essentiel d’attribuer des processus précis à une structure organisationnelle. Dans le cas contraire, les entreprises risquent de se retrouver avec un tableau de bord signalant des milliers de vulnérabilités, sans qu’aucune unité opérationnelle ne soit chargée de les corriger. Définir clairement les responsabilités en matière de sécurité dès le départ permet de passer à l’action.

Dépasser l’idée que « nous sommes des développeurs, pas des spécialistes de la sécurité »

Inciter les développeurs à adopter les pratiques de sécurité peut s’avérer difficile pour les organisations. Souvent, deux principaux obstacles compliquent la démarche : le manque de visibilité et la difficulté de mise en œuvre.

Pour commencer, la sécurité ne bénéficie pas d’une boucle de rétroaction naturelle. Les vulnérabilités s’accumulent donc souvent sans être corrigées, jusqu’à ce qu’elles soient si nombreuses que l’activité de l’entreprise en pâtisse. Les entreprises doivent exprimer clairement leurs exigences de sécurité et les rendre visibles pour tous les développeurs.

La réalité, c’est que la sécurité est tout simplement trop complexe. Pour favoriser son adoption par les développeurs, il faut la simplifier. Une erreur fréquente consiste à vouloir en faire trop, trop tôt. Pour commencer, cherchez une première victoire rapide, par exemple en mettant en œuvre la sécurité des logiciels open source et l’analyse de la composition logicielle (SCA).

« Je pense qu’il est important de montrer où vous en êtes aujourd’hui et où vous devez aller, dans une démarche d’amélioration continue. La visibilité est donc essentielle, explique Kosaraju. Il faut aussi définir des limites. Par exemple, quand vous dites que l’équipe de sécurité sécurisera l’entreprise, cela signifie-t-il qu’elle repérera les problèmes de sécurité à corriger, ou qu’elle les corrigera elle-même ? Il est essentiel de répartir clairement les responsabilités et de définir qui fait quoi. »

Au niveau du code, Twilio a créé un modèle de responsabilité en demandant à tous les développeurs d’ajouter un fichier YAML à chaque dépôt de code. Chaque fichier contient les informations nécessaires pour identifier les responsables de ces dépôts. L’équipe de sécurité peut alors créer des tickets dans la file d’attente appropriée et contacter le responsable en cas d’incident ou de vulnérabilité. L’entreprise a ainsi pu abandonner la recherche manuelle des responsables et localiser instantanément la bonne équipe, tout en automatisant la gestion des vulnérabilités.

Mesurer la sécurité, développeur par développeur

Lancer un programme de bug bounty est un excellent moyen de comprendre le retour sur investissement des outils de sécurité. Une fois le programme en place, il est possible d’intégrer des outils à différentes étapes du SDLC et de réduire le nombre de signalements de bugs. Leur diminution permet aux équipes de commencer à se concentrer sur les pratiques de sécurité intégrée en amont.

« Il est important de garder à l’esprit que l’introduction d’un nouvel outil entraîne toujours une hausse du nombre de bugs, explique Kosaraju. Il faut savoir distinguer les lacunes des outils et des capacités de sécurité. Les équipes de sécurité ne sont pas parfaites, mais reconnaître cette réalité montre que tout le monde travaille ensemble pour mieux sécuriser l’entreprise et adopter une culture de la sécurité. »

Pour que les développeurs comprennent les vulnérabilités au regard de la visibilité globale, le mieux est de mesurer le temps pendant lequel les vulnérabilités critiques restent dans une file d’attente sans être corrigées. C’est un indicateur idéal pour évaluer la réactivité des équipes. Par exemple, si l’équipe de sécurité déploie l’outil X, qui signale 30 vulnérabilités critiques, et qu’une équipe d’ingénierie en corrige 29 en deux semaines, c’est un excellent indicateur à suivre dans le temps.

Comme les responsabilités en matière de sécurité évoluent chaque année, Snyk organise régulièrement des webinaires pour recueillir différents points de vue de professionnels du secteur. Ces tables rondes permettent à Snyk de mieux comprendre les besoins des équipes de sécurité des applications et des développeurs, afin que les entreprises puissent continuer à adapter leurs produits aux besoins de sécurité d’organisations comme Twilio.