Comprendre le rapport des développeurs à la sécurité

Ils le font parce qu’ils le doivent

Pour inciter les équipes de développement à prendre en charge la sécurité, la meilleure approche consiste à en faire une composante attendue de leur rôle et de leurs objectifs. Les équipes disposent ainsi d’un mandat et des moyens nécessaires pour faire de la sécurité une priorité. Dans ce modèle, il est important que les responsabilités soient clairement définies, afin que les équipes ne supposent pas qu’une autre équipe s’occupe de la sécurité d’un projet partagé ou ancien.

Savoir ce qu’il faut faire ne suffit pas. Il est tout aussi important de mettre en place des processus qui aident les équipes à atteindre leurs objectifs de sécurité. Par exemple, leur donner accès aux résultats des tests ou leur expliquer les niveaux supplémentaires d’exposition et de risque qui apparaissent après l’écriture d’une nouvelle fonctionnalité. La visibilité et la transparence apportées par un tableau de bord peuvent favoriser la responsabilisation dont les développeurs ont besoin pour intégrer ces tâches à leur workflow. Cette approche fonctionne aussi particulièrement bien avec les équipes externalisées, qui passent souvent d’un projet à l’autre et se sentent moins responsables d’un projet — ou moins attachées à celui-ci.

Ils le font parce qu’ils le doivent

C’est une si bonne raison que nous l’avons répétée ! Une autre motivation pousse les développeurs à écrire du code sécurisé : c’est tout simplement la bonne chose à faire. Certains développeurs se soucient de la sécurité et sont particulièrement fiers, à titre personnel ou professionnel, d’écrire du code durable et sécurisé, et s’en sentent responsables.

Facilitez le bon choix (autrement dit, créez une voie toute tracée)

Chaque obstacle qui empêche un développeur d’effectuer une tâche liée à la sécurité peut l’amener à ne pas la terminer. Ces obstacles peuvent aller d’un manque de compréhension à un workflow exaspérément lent, en passant par un trop grand nombre de problèmes à traiter et l’impossibilité de savoir par où commencer. Pour favoriser l’adoption des pratiques de sécurité, il est essentiel de les intégrer facilement aux workflows existants.

Encourager l’adoption de pratiques standard grâce à une voie toute tracée est un excellent moyen d’offrir un accompagnement utile et des bonnes pratiques éprouvées. De plus, cela permet de créer une documentation et des recommandations fiables et à jour, que d’autres pourront réutiliser et actualiser régulièrement.

« Nous appelons ce concept une voie toute tracée. Vous pouvez bien sûr vous frayer un chemin à travers les bois. Mais si une belle route lisse vous mène à destination, vous choisirez probablement de l’emprunter. »

Jason Chan, vice-président chargé de la sécurité chez Netflix, dans The Secure Developer, à propos de l’empathie envers les développeurs

Réfléchissez à ce dont les développeurs ont besoin pour avancer. Analyser, tester et repérer les problèmes est relativement simple par rapport à leur correction. Un développeur ne veut pas connaître les dix vulnérabilités de son graphe de dépendances : il veut savoir si une mise à jour mineure d’une dépendance suffira à corriger les problèmes qui bloquent sa livraison. Pensez donc aux solutions plutôt qu’aux problèmes : la liste est généralement bien plus courte !

Tenez également compte du temps que les développeurs souhaitent consacrer à leurs tâches, ainsi que de la manière dont ils veulent consulter les résultats et les actions de sécurité. Tout ce qui sort de leur workflow habituel est une distraction dont ils devront se souvenir. Les intégrations aux workflows existants, conçues par des personnes qui connaissent les processus et les technologies en place, peuvent offrir une excellente expérience aux développeurs. Veillez à ce que les résultats soient utiles, les retours clairs et exploitables, et le workflow rapide et sans friction. En bref, faites preuve d’empathie envers vos développeurs.

Automatiser, encore et toujours

Les pipelines DevOps les plus performants sont fortement automatisés. Dans une étude récente, Snyk a constaté que l’automatisation était également fortement corrélée à la réussite des programmes de sécurité shift left. Les données montrent que les organisations dotées de pipelines de déploiement entièrement automatisés sont deux fois plus susceptibles d’intégrer des outils de test statique de sécurité des applications (SAST) et d’analyse de la composition logicielle (SCA) à leur cycle de développement logiciel (SDLC). En outre, celles qui automatisent entièrement leurs pipelines sont plus de quatre fois plus susceptibles de corriger les problèmes de sécurité en une journée, et plus de deux fois plus susceptibles de le faire en une semaine.

C’est évident : plus nous automatisons, plus nous pouvons exécuter de tests et détecter de problèmes. En réfléchissant soigneusement à leur mise en place, nous pouvons ajouter des garde-fous et des règles de sécurité à nos pipelines pour repérer les problèmes qui nécessitent notre attention et une intervention. Cette approche est tout à fait naturelle pour les développeurs, qui automatisent déjà des tâches comme les tests d’intégration.

En outre, automatiser la sécurité réduit aussi les tensions entre les équipes de sécurité et de développement, car c’est un processus — et non une équipe ou une personne — qui signale qu’un problème doit être corrigé. L’équipe de sécurité peut ainsi soutenir l’équipe de développement et l’aider à résoudre les problèmes qui requièrent son expertise, au lieu de devenir un goulot d’étranglement ou de n’apporter que de mauvaises nouvelles.

« À mon avis, il faut intégrer automatiquement tous les outils de sécurité pertinents à leur pipeline DevOps. J’aurais aimé que nous l’ayons fait plus tôt. Il faut pouvoir signaler un problème dans le code aux développeurs le plus tôt possible, de manière automatisée. Idéalement, on le détecte dès l’envoi du code, pour qu’ils en prennent conscience à ce moment-là, ou même pendant qu’ils écrivent leur code, grâce à un outil qui signale immédiatement un problème dans leur IDE. La mise en place de cette automatisation est essentielle. Essayer de corriger un problème juste avant la mise en production d’un produit est beaucoup plus difficile. »

Ryan Ware, architecte de la sécurité et directeur de l’équipe Intel Products Assurance and Security Tools

Formation et connaissances en développement sécurisé

La formation peut être une réussite ou un échec auprès des équipes de développement, en particulier lorsqu’elles doivent suivre de nombreux cours et supports sans rapport avec leur travail, puis consacrer du temps à un bref examen. Tout cela finit probablement par se résumer à une case cochée dans une liste de conformité à la formation.

Intégrer la formation au quotidien des développeurs, de façon à les aider dans leur travail, à corriger un bug ou à développer de manière plus sécurisée, accélère l’adoption de la sécurité. Le cours ou le module de formation doit leur être utile, renforcer leur sécurité et produire rapidement des effets concrets.

Lorsque vous réfléchissez à la formation, demandez-vous comment elle peut aider vos équipes à se concentrer sur le développement sécurisé. Pensez aux actions qu’elles pourront retenir et appliquer à leurs processus ou workflows. Réfléchissez à la façon de cibler la formation pour leur apporter une aide pertinente au moment où elles en ont le plus besoin. Veillez à ce qu’elle ne porte pas uniquement sur la technologie, mais aussi sur les processus et la culture.

Voici quelques conseils pour tirer le meilleur parti de votre formation à la sécurité :

• La formation doit être suffisamment intéressante pour qu’elles aient envie de la suivre. Pour en améliorer facilement la qualité, lancez des programmes pilotes, recueillez des retours et apportez des ajustements avant de la déployer à grande échelle.

• Gardez à l’esprit que les vecteurs d’attaque peuvent varier considérablement d’une équipe de développement à l’autre et proposez des cours adaptés. Par exemple, les attaques par traversée de répertoires concernent davantage les développeurs backend.

• Lorsque vous abordez les vulnérabilités en formation, choisissez celles qui concernent l’équipe, en fonction des langages, frameworks, bibliothèques, etc. utilisés. Des récits d’incidents ayant touché d’autres entreprises dans des écosystèmes similaires peuvent illustrer les conséquences possibles.

• Il est utile de présenter des exemples concrets de problèmes de sécurité, mais ne faites pas de la peur votre principal levier de motivation. Cela peut susciter une réaction à court terme, mais ce n’est pas une stratégie durable. Sauf pour les problèmes de sécurité véritablement effrayants, comme ceux qui pourraient dévaster une entreprise !

• Ajoutez la formation aux tableaux de bord de suivi pour responsabiliser les équipes quant à son suivi.

• Veillez à ce que la formation explique comment prévenir des attaques concrètes. Si vous présentez une vulnérabilité, montrez comment elle peut être exploitée. Si vous expliquez comment renforcer une partie d’un pipeline, décrivez la surface d’attaque ainsi réduite. Rendez le tout concret et tangible.

• Veillez à ce qu’une documentation soit disponible pour toutes les tâches que vous souhaitez confier aux développeurs. Demandez-leur de vérifier son utilité ou, mieux encore, de la rédiger eux-mêmes pour le prochain développeur ou la prochaine équipe. N’oubliez pas que la documentation ne remplace pas les garde-fous, mais qu’il faut aussi documenter ces derniers.

• Si une équipe rouge détecte un incident, profitez-en pour créer une formation pertinente et réaliste. Une analyse approfondie de l’incident rend les risques concrets. Si possible, faites participer l’équipe rouge à une session de questions-réponses.

Pourquoi les développeurs évitent-ils la sécurité ?

Nous avons vu pourquoi les développeurs prennent le temps de créer des logiciels sécurisés. Mais il est tout aussi important, voire davantage, de comprendre pourquoi ils résistent et évitent de prendre des mesures supplémentaires pour livrer du code sécurisé.

Les frictions

Les obstacles relevés par les équipes varient en fonction de leur niveau d’adoption de la sécurité et de leur maturité en matière de développement moderne. Les équipes qui débutent leur parcours de sécurité manifestent des réticences lorsque les raisons et la valeur des changements de processus ne sont pas clairement expliquées. Le nouveau processus doit s’intégrer sans perturber le travail de l’équipe de développement et respecter ses workflows. Pour favoriser son adoption, communiquez largement, réduisez les frictions en intégrant la sécurité aux processus existants et, dans la mesure du possible, regroupez les outils pour simplifier l’ensemble.

« Je pense que l’un des principaux défis a été de faire comprendre aux parties prenantes clés des équipes technologiques et aux développeurs l’importance et la valeur de la sécurité. Dans un monde idéal, cette compréhension serait déjà acquise. Un développeur n’aura pas beaucoup de motivation à faire quelque chose s’il n’en voit pas l’intérêt. C’est pareil pour un responsable produit, un responsable de développement ou même un directeur de l’ingénierie logicielle. S’ils ne comprennent pas la valeur de la sécurité, ils n’auront pas vraiment de raison de la faire passer [avant] le développement de leurs fonctionnalités. »

Nicholas Vinson, responsable DevSecOps chez Pearson

La méfiance

Apporter de la valeur et préserver ou gagner la confiance sont indispensables pour mettre en place un processus durable que les équipes suivront dans le temps. Si elles perdent confiance dans les données, les outils ou le processus, elles finiront par y voir un obstacle et chercheront à le contourner. Par exemple, les faux positifs récurrents d’un outil ou d’un processus découragent ou agacent les développeurs. Ils risquent alors davantage d’ignorer ou d’écarter les résultats liés à de véritables vulnérabilités ou problèmes que si les données leur inspiraient confiance.

La complexité

De même, lorsque les outils compliquent des problèmes existants sans aider à les détecter ni proposer de solution, ils ne font qu’ajouter du travail pour les développeurs. La détection d’une vulnérabilité n’est que le début. Le développeur doit encore identifier toutes les façons dont elle est accessible dans l’application et tous les endroits concernés — par exemple, les différents chemins dans le graphe de dépendances. Il doit savoir immédiatement si elle peut être corrigée et, dans l’affirmative, comment procéder. Les développeurs ont besoin d’outils intuitifs et pédagogiques pour mettre rapidement en œuvre les solutions.

La responsabilité

Une autre raison pour laquelle une tâche peut ne pas être reprise par quelqu’un d’autre est le manque de clarté des responsabilités. Pour les projets ou fonctionnalités récents, les responsabilités peuvent être clairement définies : aucune autre équipe ne touche au code concerné. Mais qu’en est-il lorsqu’une partie de l’application est un service partagé, utilisé et alimenté par de nombreuses équipes, sans qu’aucune n’en soit pleinement responsable ? Qui prendra en charge un bug ou un problème de sécurité qui ne l’affecte pas directement ? Les images de conteneurs utilisées par plusieurs équipes en sont un autre exemple courant. Lorsque chaque équipe se démène pour livrer ses propres fonctionnalités, le code partagé est souvent laissé de côté et personne ne se saisit de ces problèmes.

Le temps

Bien sûr, même lorsque les responsabilités sont clairement définies, il reste difficile de trouver le temps d’intégrer la sécurité au flux de travail. Même si l’automatisation permet de tester votre code, ce n’est que la partie facile. Le vrai travail consiste pour les développeurs à analyser les résultats et à corriger les problèmes. Plus les outils génèrent de faux positifs ou proposent des mesures correctives peu claires ou non automatisées, plus le risque qu’on les abandonne augmente. De même, si l’organisation ne donne pas la priorité aux corrections et aux activités de sécurité, les développeurs résisteront ou ignoreront les demandes des équipes de sécurité qui leur demandent de tester ou de corriger leur code.

La responsabilisation

La responsabilisation est un pilier essentiel de la sécurité des développeurs, mais il est tout aussi important de savoir envers qui ils doivent rendre des comptes. Par exemple, un développeur sera probablement davantage motivé à agir si son équipe, un référent sécurité au sein de celle-ci ou un membre de sa hiérarchie lui demande des comptes. En revanche, si seule l’équipe de sécurité le responsabilise, sans conséquence clairement définie, il ressentira moins de pression pour sécuriser son travail.

Le manque de modèles

Les êtres humains s’inspirent du comportement de leur entourage. Si nous ne voyons personne développer de manière sécurisée ni d’autres équipes intégrer la sécurité à leurs projets, il est facile de suivre le mouvement et d’ignorer les tâches de sécurité. Pour y remédier, vous pouvez notamment rendre les enjeux de sécurité visibles lors des revues de code, afin que les questions de sécurité soient posées et que le sujet retienne l’attention. Autre solution : créer des modèles à suivre !

Mettez en avant les personnes dont vous souhaitez voir le comportement se généraliser dans l’organisation. Soulignez les réussites des équipes et les progrès accomplis pour intégrer la sécurité à leur pipeline ou réduire leur backlog de sécurité. Veillez à ce que les réussites en matière de sécurité soient visibles, célébrées par les responsables de l’ingénierie et que d’autres puissent les reproduire grâce à la documentation, à l’automatisation, etc.