In this article
Bonnes pratiques pour favoriser l’adoption des outils et processus de sécurité par les développeurs
Introduction à l’adoption de la sécurité par les développeurs
Il est largement admis que, pour déployer la sécurité des applications à grande échelle dans les organisations modernes, il faut l’intégrer directement aux workflows de développement, comme une composante naturelle des processus agiles et des pipelines DevOps. C’est toutefois plus facile à dire qu’à faire, et cela soulève de nombreux défis en matière d’acceptation et d’adoption par les développeurs et les équipes de développement. Ce livre blanc présente les enseignements tirés de nos échanges avec différentes organisations dont les programmes DevSecOps sont à des stades de maturité variés. Toutes les personnes et équipes avec lesquelles nous avons échangé souhaitaient que les équipes de développement adoptent des pratiques de développement sécurisé dans leurs workflows.
Il est important de noter qu’aucune des équipes avec lesquelles nous avons échangé ne travaille de la même manière. Il est tout aussi important de préciser que ce qui fonctionne bien dans une organisation peut ne pas être aussi efficace dans une autre, car de nombreux facteurs peuvent influer sur la réussite de ces pratiques. À vous, lecteur, de repérer dans ce livre blanc les pratiques et approches qui conviendraient le mieux à votre organisation, à sa culture et à vos équipes.
La sécurité du développement repose sur la culture, les processus et les outils
Culture
1. Faites preuve d’empathie envers vos équipes de développement
Comprenez leur appétence générale pour le changement.
Déterminez quelles équipes et quels projets sont susceptibles d’adopter les technologies et processus de développement modernes, et lesquels résistent au changement.
Déterminez dans quelle mesure la responsabilité et la propriété des projets sont clairement définies.
Évaluez la capacité des équipes à livrer, ainsi qu’à accomplir d’autres tâches liées, par exemple, aux performances et à la fiabilité.
2. Adhérez à la priorisation de la sécurité par la direction
Précisez clairement quand les priorités sont définies par l’entreprise.
Les équipes de sécurité doivent aider les équipes de développement à répondre aux priorités de sécurité de l’entreprise, plutôt que de leur ajouter des tâches.
3. Favorisez la collaboration entre les équipes de développement et de sécurité
Envisagez de créer un programme de référents sécurité ou une communauté de pratique pour faciliter la collaboration.
Collaborez avec les développeurs pour instaurer un climat de confiance, plutôt que de miser sur la peur pour obtenir des résultats.
Créez des programmes communs et fixez des objectifs partagés entre les équipes de sécurité et de développement.
Identifiez les responsables au sein des équipes de développement afin que les demandes des équipes de sécurité soient pertinentes.
4. Formez les équipes pour favoriser le développement sécurisé
Formez les équipes avant de déployer des programmes.
Gardez à l’esprit que certaines formations ne sont pas pertinentes pour toutes les équipes.
Formez les équipes aux vulnérabilités spécifiques qui les concernent, en vous appuyant sur des incidents passés comme exemples.
Suivez les formations à l’aide de tableaux de bord.
Gamifiez les formations lorsque c’est possible.
5. Récompensez et valorisez les réussites
Mettez en avant les réussites et les progrès en matière de sécurité de chacun.
Soulignez les réussites des équipes et l’adoption des programmes pour montrer leur progression et encourager d’autres déploiements.
Veillez à ce que la direction de l’ingénierie valorise les équipes et leur montre que la sécurité est importante.
Offrez des produits dérivés, des cadeaux, des voyages à des conférences sur la sécurité, etc., pour sensibiliser les équipes.
Processus
1. Associez les développeurs aux décisions qui modifient les processus
Comprenez comment les équipes de développement intègrent actuellement les pratiques de sécurité à leurs pipelines, puis essayez de vous adapter à leurs workflows.
Lors de la création de nouvelles règles ou de nouveaux processus de sécurité, définissez les seuils et les pratiques de travail avec les équipes de développement.
Veillez à communiquer et à sensibiliser les équipes à tout changement de processus bien à l’avance, notamment au moyen de blogs, de documentation et de centres de formation.
2. Faites du bon choix le choix le plus simple
Ne complexifiez pas les processus. Collaborez avec l’équipe de développement pour les simplifier.
Veillez à bien documenter le fonctionnement des autres équipes et la manière dont les activités doivent être réalisées.
Proposez aux développeurs des parcours recommandés pour les aider à faire le bon choix par défaut.
Intégrez les processus aux workflows existants plutôt que d’essayer d’en créer de nouveaux.
Veillez à ce que les processus (et les outils) privilégient les solutions plutôt que les problèmes.
3. Assurez visibilité et transparence entre les équipes
Les tableaux de bord sont un excellent moyen de rendre compte à l’organisation de l’avancement et de l’état de la sécurité.
Les équipes doivent répondre des résultats présentés dans les tableaux de bord et prioriser la sécurité en fonction de leur niveau de maturité et de leurs plans.
Appuyez-vous sur les valeurs des développeurs et la gamification pour intégrer les tâches aux sprints, en justifiant leur priorité par les données des tableaux de bord.
4. Déployez progressivement
Identifiez les équipes les plus adaptables et les plus ouvertes à l’introduction de nouveaux programmes de sécurité.
Commencez par ces équipes, avec une approche peu intrusive axée sur la visibilité.
Intégrez des activités de développement sécurisé aux workflows, en commençant par sécuriser les modifications incrémentales apportées aux applications.
Renforcez progressivement les garde-fous, au rythme auquel les équipes peuvent absorber les changements sans être submergées.
Une fois que les équipes pionnières auront démontré la valeur de l’approche, identifiez d’autres équipes auxquelles la déployer.
Appuyez-vous sur les bonnes pratiques identifiées lors du déploiement initial pour favoriser l’adoption.
Outils
1. Misez sur les outils des développeurs
Les outils de sécurité destinés aux développeurs doivent être faciles à utiliser en libre-service, avec une prise en main simple, des workflows intuitifs et une documentation claire.
Les outils doivent s’intégrer aux workflows existants, notamment aux IDE, à Git et aux pipelines.
Les outils doivent proposer des API complètes et se prêter facilement à l’automatisation.
Privilégiez les outils largement adoptés par les communautés open source et de la sécurité.
Essayez de choisir un outil qui couvre l’ensemble de l’application, notamment le code propriétaire, les bibliothèques tierces, les conteneurs, l’IaC, etc.
Les outils doivent privilégier la correction et la résolution des problèmes plutôt que leur simple détection et signalement.
2. Ne submergez pas les développeurs
Lors de l’introduction d’outils dans une organisation ou une équipe, utilisez-les d’abord pour gagner en visibilité.
Au fil du temps, renforcez les règles et les garde-fous au moyen de politiques afin d’améliorer le processus de développement sécurisé.
Accompagnez tout changement d’outillage par des actions de sensibilisation et de communication, des explications, une documentation claire des processus et des formations.
Concentrez d’abord les outils sur la livraison de nouveau code, puis traitez les problèmes accumulés afin de réduire la charge des développeurs.
3. Automatisez tout
L’intégration à un workflow doit être automatisée et effectuée au bon endroit, en fonction de l’équipe.
Outre les tests intégrés au workflow, recherchez d’autres points d’intégration pour connecter les outils (gestion des tickets, rapports, alertes, etc.).
Vous devez pouvoir extraire les données de reporting de vos outils, de préférence via une API, afin d’alimenter vos tableaux de bord et tableaux de suivi existants.