Réussir son programme DevSecOps

Améliorer la sécurité du développement est un processus qui prend du temps. Tout commence par une meilleure visibilité sur les processus et les pratiques de sécurité que chaque équipe applique aujourd’hui. Si cette démarche manque d’empathie, elle peut être perçue comme une réaction aux lacunes du développement. Lorsque les autres ont l’impression d’être blâmés ou jugés, ils risquent de se mettre sur la défensive. Pour éviter cela, une bonne approche consiste à demander au responsable du programme de remplir une grille d’autoévaluation des processus et des pratiques de son équipe. Cela lui permet de prendre le temps de réfléchir, sans créer de dynamique opposant « eux » à « nous ». Cette grille se compose de questions portant sur différents comportements en matière de sécurité, types de tests, processus, etc. L’équipe de développement peut indiquer le niveau de mise en œuvre actuel dans chaque domaine. Il est courant que les équipes mettent davantage l’accent sur certains domaines que sur d’autres, et c’est tout à fait normal.

L’étape suivante consiste à progresser, et c’est là que l’équipe de sécurité peut aider et accompagner les équipes de développement. Un excellent exemple d’amélioration menée par les développeurs consiste à leur demander quels éléments de la grille ils souhaitent améliorer. Il leur suffit d’en choisir quelques-uns, puis de s’engager sur une date à laquelle le processus d’amélioration sera mis en place. Ils peuvent par exemple vouloir intégrer des questions de sécurité aux revues de code, ou éliminer de leur backlog toutes les vulnérabilités de gravité élevée ayant un score CVSS de 9,5 ou plus. Quel que soit l’objectif, il est important qu’il soit défini et pris en charge par les développeurs. Le coach en sécurité aide le responsable du programme à le concrétiser. Qu’il s’agisse de formation, de conseils, de modifications du pipeline, etc., il peut aider le responsable à déployer le changement souhaité.

Un principe fondamental est que la réussite du coach en sécurité (et éventuellement un KPI officiel) dépend de celle du responsable du programme de sécurité. Le coach ne réussit que si le responsable atteint son objectif ou progresse conformément à son plan. Cette mesure commune de la réussite reflète l’objectif partagé par les deux équipes : améliorer ensemble la sécurité du développement.

La gestion des vulnérabilités est une autre activité courante des programmes de référents sécurité. Savoir où se trouvent les vulnérabilités est précieux, car cela met en évidence les points sensibles de vos applications et déploiements. Toutefois, dans les projets et déploiements de grande envergure, le nombre de vulnérabilités dans les backlogs des développeurs peut vite devenir écrasant. Le triage des vulnérabilités, leur mise de côté ou leur priorisation, qu’elles figurent déjà dans les backlogs ou viennent d’être détectées, peuvent être pris en charge par les équipes de développement et de sécurité. Les équipes de développement connaissent bien mieux les flux applicatifs, l’architecture et la conception que l’équipe de sécurité. De même, l’équipe de sécurité connaît mieux les menaces et les risques que les développeurs. Grâce à une collaboration et à des échanges ouverts, notamment dans le cadre d’une relation entre un référent et un coach, ces discussions et évaluations sont bien plus simples et rapides.

Comment lancer et déployer un programme de référents sécurité

Avant tout, gardez à l’esprit que la clarté et la simplicité sont essentielles. Au lancement, veillez à ce que chacun puisse trouver suffisamment d’informations pour comprendre en quoi consiste le programme de référents sécurité, quels sont ses objectifs, et pourquoi il est important et soutenu par l’entreprise. Rédigez ces informations en pensant aux développeurs et demandez-leur leur avis.

La principale leçon à retenir pour définir la taille initiale du programme : ne cherchez pas à le déployer trop largement, trop vite. Repérez et apprenez les bonnes pratiques propres à votre organisation et à vos équipes, afin de pouvoir les appliquer lors du déploiement à plus grande échelle. Pour choisir les équipes qui participeront à la première phase, déterminez lesquelles dans votre organisation correspondent aux critères suivants :

• Les services, applications et équipes les plus essentiels à votre activité et présentant le risque le plus élevé

• Les équipes les plus matures en matière de sécurité et de développement, capables de s’adapter au changement

• Les équipes dont certains membres entretiennent déjà des relations avec l’équipe de sécurité

• Les équipes dont certains membres s’intéressent à la sécurité et sont prêts à améliorer la posture et les pratiques de sécurité de leur équipe.

Commencer avec seulement quelques équipes réduit le risque d’échec du déploiement : vous pouvez consacrer à chacune tout le temps nécessaire. Pour cerner les besoins des équipes, vous pouvez aussi rechercher les problèmes qu’elles ont en commun, si vous les connaissez déjà à ce stade. Par exemple, si vous déployez le programme auprès de trois équipes qui souhaitent toutes commencer à adopter la modélisation des menaces, vous pouvez partager leurs retours et concentrer vos efforts sur un nombre réduit de sujets.

Le choix du coach en sécurité est tout aussi important, car il sera le principal interlocuteur des équipes de développement. Une personne qui communique bien, possède de préférence une expérience en ingénierie et fait preuve d’empathie envers les développeurs peut faire toute la différence.

Au début, soyez généreux dans vos récompenses et marques de reconnaissance pour encourager les participants et leur donner envie de s’investir davantage. Commencez à constituer un guide des bonnes pratiques qui servira plus tard à d’autres équipes. Mettez également à jour la documentation et les guides existants afin que les prochaines équipes disposent d’informations pertinentes et à jour.

À mesure que le programme s’étend à l’ensemble de l’entreprise, vous pouvez intégrer d’autres groupes issus de différentes parties de l’organisation pour mieux représenter toutes vos activités. Vous pouvez aussi organiser une tournée de présentation afin de recueillir des informations sur les autres besoins auxquels vous ne répondez pas, et de partager les réussites des équipes déjà participantes. Partager ces réussites au sein du programme permet aux équipes de voir les progrès des autres, crée souvent une saine émulation et les pousse à s’améliorer mutuellement.

Lorsque vous déployez le programme auprès d’une équipe de développement, valorisez ses initiatives, ses nouveaux apprentissages et le fait qu’elle assume davantage de responsabilités… en lui confiant encore plus de responsabilités ! Cela peut sembler étrange, mais notre objectif est que les équipes de développement gagnent en autonomie. Lorsqu’elles démontrent leur capacité et leur volonté à prendre en charge la sécurité, donnez-leur plus d’autorité et de responsabilités.

Obtenir l’adhésion des développeurs

Pour obtenir l’adhésion des développeurs à votre programme, il est essentiel de comprendre les difficultés et les besoins de l’organisation de développement. Que vous choisissiez de faire grandir le programme uniquement avec des volontaires, par sélection de la direction ou selon une formule mixte, veillez à ce que les participants s’y investissent et contribuent.

Il est important d’expliquer clairement la raison d’être du programme. En précisant ses objectifs ainsi que les rôles et responsabilités des équipes de développement et de sécurité, vous aiderez chacun à se sentir à l’aise et à s’impliquer. L’un des principes fondamentaux du programme est que les équipes de développement et de sécurité travaillent ensemble pour atteindre un objectif commun : développer et livrer du code et des applications sécurisés. Pour obtenir l’adhésion et l’enthousiasme des développeurs, il est particulièrement important que le travail lié à la sécurité soit considéré avant tout comme du travail de développement.

Lorsque vous choisissez des sujets de formation, demandez aux développeurs d’effectuer des tâches ou suivez des tickets, gardez toujours à l’esprit les besoins de votre public. Les développeurs s’intéressent souvent davantage aux bonnes pratiques qu’aux notions de base qu’ils connaissent déjà. Pour être efficace, le contenu doit être concret, technique et applicable à la résolution de problèmes.

Les détails comptent souvent, notamment le lieu des échanges et des interactions. Par exemple, si vous souhaitez créer un ticket pour l’équipe de développement, utilisez son système de gestion des tickets habituel. Si elle utilise déjà Jira, créez des tickets Jira. Chaque outil ou service supplémentaire que vous demandez à l’équipe de développement d’utiliser peut constituer un obstacle de plus à sa participation.

Comme indiqué, il est tout aussi important de définir clairement les responsabilités et les tâches attendues des référents sécurité. C’est plus facile lorsqu’il s’agit d’un rôle officiel qui précise le temps que la personne doit consacrer aux activités de sécurité de l’équipe. Dans tous les cas, énoncez deux ou trois objectifs et activités sur lesquels les référents devront travailler au cours des 3 à 6 prochains mois. C’est suffisant pour éviter de les submerger et les aider à se concentrer sur les activités les plus importantes.

Nous avons évoqué plus tôt l’importance des récompenses et de la reconnaissance, ainsi que quelques idées pour montrer la valeur de ces activités pour l’entreprise. Célébrer une réussite ne signifie pas forcément envoyer quelqu’un à une conférence. Le plus souvent, il s’agit de mettre en avant les efforts d’une personne pour l’encourager à poursuivre, en devenant son défenseur ou son porte-parole. Ce comportement incite également les autres à faire un effort supplémentaire pour bénéficier de la même reconnaissance.

À quoi ressemble la réussite ?

Avant tout, ne vous attendez pas à des résultats exceptionnels en quelques semaines, ni même en quelques mois. Un programme de ce type vise à améliorer les processus et les pratiques de développement afin de pouvoir livrer des logiciels de manière sécurisée. Il n’existe pas de solution instantanée, et lorsque des personnes sont concernées, le changement prend encore plus de temps. Pour prendre les bonnes décisions plutôt que de viser un objectif arbitraire, il faut prévoir des délais réalistes pour le changement et la réussite.

Adoption

Un indicateur essentiel pour tout programme de référents sécurité est le niveau d’adoption. Comme nous l’avons indiqué, la participation de chaque référent doit être volontaire. Le nombre total de référents, la croissance du groupe au fil du temps et leur fidélisation peuvent donc être des signes de réussite.

Un autre indicateur utile consiste à suivre le nombre d’équipes de développement touchées par le programme de référents sécurité et la part de l’organisation de développement qu’elles représentent. N’oubliez pas qu’une croissance trop rapide peut facilement faire échouer le programme : vos objectifs doivent être atteignables et progresser naturellement, plutôt que d’être trop ambitieux ou imposés.

Engagement

L’engagement des participants est le prochain indicateur à suivre : il permet de savoir si le programme et les relations établies sont efficaces. Il est difficile de vérifier si les référents consacrent réellement 10 à 20 % de leur temps aux activités de sécurité, et vous ne voudrez probablement pas le faire. Il s’agit plutôt de soutenir officiellement les ingénieurs en intégrant ce travail de sécurité à leurs fonctions, au lieu d’en faire une tâche supplémentaire qu’ils accompliraient — ou non — sur leur temps libre. Par ailleurs, le temps consacré est une estimation : il varie d’une semaine à l’autre selon les besoins.

Il est bien plus pertinent de suivre les activités auxquelles ils participent, des réunions régulières aux initiatives qu’ils mènent au sein de leurs équipes. Pour les premières, il suffit de noter combien de référents assistent régulièrement aux réunions mensuelles ou participent aux échanges hebdomadaires avec leur coach en sécurité. Ces données ne doivent pas être utilisées pour sanctionner les référents, mais plutôt pour améliorer le contenu et les activités du programme et les rendre plus attrayants et pertinents à leurs yeux.

Impact

Comme indiqué précédemment, il est important de donner à l’équipe de développement les moyens de prendre en charge les changements et les améliorations au sein de l’équipe. À vous de décider jusqu’où vous souhaitez aller, mais comprendre ce que l’équipe prend en charge, ce qu’elle améliore et ce qu’elle a terminé permet de mesurer concrètement l’impact du programme.

Pour y parvenir avec la méthode des tableaux de bord, vous pouvez demander à l’équipe de développement d’évaluer elle-même ses pratiques et ses processus. Tout d’abord, combien de personnes remplissent un tableau de bord pour leur équipe ? Après les avoir aidées à identifier les risques majeurs et les solutions les plus rapides, ont-elles élaboré un plan d’amélioration qu’elles s’approprient et pilotent, avec le soutien de l’équipe de sécurité ? Il faut bien sûr aussi mesurer la progression des équipes par rapport à leur plan. Le champion et son coach doivent tous deux être responsables d’un KPI qui mesure cette progression.

Progression

Comme nous l’avons déjà mentionné, les besoins en formation d’un champion diffèrent de ceux d’un développeur moins intéressé par la sécurité. Cela dit, il reste utile de mesurer et de suivre leur progression. Une fois votre approche de formation définie — en interne, via des certifications externes, voire en comptabilisant des heures ou des activités pratiques liées à la sécurité —, utilisez un système de niveaux ou de médailles et de certifications pour évaluer le niveau de compétence de vos équipes, avec des objectifs de progression à atteindre chaque trimestre.

Tableaux de bord

Le dernier domaine à mesurer, qui peut être considéré comme un indicateur d’influence, concerne les tableaux de bord de sécurité des produits. Ils présentent des statistiques sur les vulnérabilités, le nombre de tests, l’adoption par les équipes, etc. Sans contexte, ces chiffres ne reflètent pas nécessairement la qualité ni le niveau de risque d’un projet. Par exemple, si une équipe effectue plus de tests qu’une autre, elle trouvera probablement davantage de vulnérabilités, car elle a une meilleure visibilité sur ses problèmes. Cela ne signifie pas qu’elle présente un risque plus élevé, même si les chiffres sont supérieurs.

Pouvoir présenter l’impact par équipe, avec le contexte et les explications nécessaires, est très utile. Lorsque vous suivez ces indicateurs, veillez également à mesurer les processus et les pratiques qui les influencent. Par exemple, demander à votre équipe de réaliser une modélisation des menaces pour chaque fonctionnalité qu’elle développe réduit considérablement le risque associé au projet. Cela aura une incidence sur le nombre de vulnérabilités détectées au cours du développement, et ce contexte enrichit considérablement l’analyse des résultats.