Donner à vos développeurs les moyens d’agir

Donner aux développeurs les moyens d’agir, c’est leur laisser la latitude de prendre leurs propres décisions en fonction de différents éléments, de résoudre leurs problèmes de sécurité et, au bout du compte, d’assumer la responsabilité de la sécurité de leurs applications. L’autonomie nécessite un accompagnement. Elle se construit et se développe grâce au soutien des autres équipes. Commençons par le soutien de la direction, indispensable pour permettre aux développeurs de consacrer le temps nécessaire à la livraison d’un code sécurisé.

« Quand on lit le mémo sur la culture de Netflix publié sur son site web, l’un des points qui retient souvent l’attention est cette réflexion sur la liberté et la responsabilité. Ce concept a guidé le fonctionnement de leur organisation d’ingénierie. C’est intéressant parce qu’en tant qu’êtres humains, nous avons tendance à nous focaliser sur la liberté. On se dit : “C’est génial, je peux faire ce que je veux. Et je vais sûrement devoir assumer certaines responsabilités, mais on verra bien.” En réalité, il y a une énorme responsabilité quand on développe des logiciels pour une entreprise comme Netflix. On ne veut pas que le service tombe en panne : la fiabilité est donc essentielle. On ne veut pas qu’il soit piraté : la sécurité est donc tout aussi essentielle. En tant qu’ingénieur, il faut donc faire preuve d’un grand sens des responsabilités. De notre côté, au sein de l’équipe de sécurité, nous nous considérions souvent comme là pour aider l’entreprise et lui donner les moyens d’agir. Nous voulions permettre aux ingénieurs logiciel de l’entreprise de se concentrer, dans les faits, sur les domaines pour lesquels ils avaient été recrutés. Mais si la sécurité devenait vraiment essentielle à leur travail, ils pouvaient compter sur nous. Et déterminer précisément où se situe cette limite relève du jugement. Une bonne relation entre l’équipe de sécurité et les ingénieurs permet de trouver la réponse. »

Bryan Payne, CISO chez BetterUp, ancien directeur de l’ingénierie, de la sécurité des produits et des applications chez Netflix

Qu’est-ce qui incite les développeurs à consacrer du temps à la sécurité ?

Que les développeurs souhaitent ou non consacrer du temps à la sécurité, il faut leur en donner les moyens, de façon à ce qu’elle puisse être priorisée au même titre que les autres livrables fonctionnels ou non fonctionnels. Les développeurs doivent pouvoir décider du temps à consacrer aux pratiques de développement sécurisé, par rapport aux enjeux de fiabilité ou de mise à l’échelle, en fonction des besoins de l’entreprise. Lorsqu’ils prennent ces décisions, ils doivent pouvoir rendre compte de leurs actions et de leurs résultats lors de leur entretien annuel, avec le soutien de leur manager. Il revient ensuite aux managers de valoriser leurs décisions afin que les développeurs sachent qu’ils ont bien utilisé leur temps. Si ce n’est pas le cas, l’entreprise ne leur donne pas les moyens de consacrer du temps au développement sécurisé.

Qui doit donner la priorité à la sécurité de l’équipe et de l’entreprise ?

En définitive, l’impulsion doit venir du sommet : le CEO. Si la sécurité est un enjeu pour l’entreprise, elle doit aussi être un enjeu pour le CEO. Cette priorité doit ensuite se diffuser dans toute l’organisation : du CIO et du CTO aux SVP/VP de l’ingénierie, aux directeurs, aux managers et aux responsables d’équipe, jusqu’aux développeurs qui exécutent les tests et corrigent les problèmes. Une fois que la direction soutient cette démarche, les équipes peuvent consacrer une partie de leurs sprints à la santé de l’ingénierie, sécurité comprise, au lieu de devoir toujours se concentrer sur les nouvelles fonctionnalités.

Sans ce soutien et cette priorisation de la direction, il est extrêmement difficile de faire valoir que les tests de sécurité sont aussi importants, voire plus importants, que la prochaine fonctionnalité ou le besoin d’un client. Si ce type d’action ou d’activité est considéré comme un supplément à justifier, la réaction par défaut devient « ne rien faire », et les discussions commencent par « pourquoi » plutôt que par « comment ».

Cela ne signifie pas que le CEO et les développeurs agissent pour les mêmes raisons immédiates. Un développeur est fier de son code. Il veut qu’il soit précis, rapide, fiable et sécurisé. Le CEO, lui, se soucie de la marque et des résultats financiers, et s’inquiète des conséquences qu’un incident de sécurité ou une fuite de données pourrait avoir sur l’entreprise. Ces deux raisons de sécuriser les applications sont valables, mais une approche descendante de l’adoption de la sécurité aura davantage d’impact que de compter uniquement sur les développeurs pour alourdir leur charge de travail.

« Pour obtenir l’adhésion de la direction, nous sommes partis du CISO, qui avait l’oreille du CTO. La démarche est donc venue du sommet de l’organisation technologique. Dès le départ, la nécessité de la sécurité était comprise. Pour la mise en œuvre, tout dépend de l’organisation d’ingénierie logicielle et de ses responsables. »

Nicholas Vinson, responsable DevSecOps chez Pearson

Votre équipe de sécurité accompagne-t-elle vos développeurs ?

Il incombe à l’équipe de développement de sécuriser ses applications et son code, mais elle a besoin du soutien de l’équipe de sécurité pour y parvenir efficacement. Quand elles travaillent ensemble, l’équipe de sécurité cesse de jouer le rôle d’auditeur, qui exécute les tests et communique les résultats (et est perçu comme un obstacle), pour devenir davantage une équipe d’ingénierie de la sécurité. Elle aide alors les développeurs à automatiser ces tâches dans leurs processus et leur apporte des conseils et une expertise sur les risques les plus élevés et leur priorisation.

L’équipe de sécurité ne peut pas obliger les développeurs à donner la priorité aux tâches de sécurité plutôt qu’à leurs autres missions. Comme indiqué plus haut, cette décision relève des priorités globales de l’équipe d’ingénierie et de l’entreprise. Historiquement, les développeurs ont souvent considéré les équipes de sécurité comme des obstacles, car elles leur transmettaient les résultats d’audits de sécurité tard dans le cycle de développement. En donnant aux développeurs les moyens de réaliser leurs propres audits et de tester eux-mêmes leur code, l’équipe de sécurité peut prendre du recul. Elle peut alors aider les équipes de développement à traiter les résultats qui nécessitent une expertise en sécurité, passant ainsi du rôle d’obstacle à celui de facilitateur. Cette approche permet également à l’équipe de sécurité d’identifier des référents sécurité au sein des équipes de développement, et d’ouvrir encore davantage de possibilités de collaboration.

L’équipe de sécurité peut également sensibiliser les équipes de développement aux types de vulnérabilités et aux risques d’exploitation. Cela peut se faire dans le cadre de programmes officiels de référents sécurité, qui permettent aussi de coordonner d’autres activités, comme le déploiement de processus. Même si les équipes de développement gagnent en autonomie, une gouvernance globale et une bonne visibilité restent nécessaires pour que l’entreprise comprenne ses risques et son exposition. L’équipe de sécurité peut définir des garde-fous, appuyés par des politiques de tests de sécurité, à appliquer aux pipelines et aux pratiques. Elle aide ainsi les équipes de développement à détecter les problèmes en amont et à respecter leurs SLA.

« Quand je pense aux référents sécurité et aux modèles efficaces, vous identifiez plusieurs personnes au sein des équipes d’ingénierie qui sont responsables de la sécurité. Vous établissez un tableau de bord dont elles sont responsables, qui montre concrètement les mesures prises pour sécuriser correctement notre produit ou notre fonctionnalité. Les ingénieurs peuvent échanger avec l’équipe centrale de sécurité selon leurs besoins, et nous leur proposons également les formations les plus récentes. Si l’équipe de sécurité est chargée de créer des outils, par exemple, ces référents contribuent à en favoriser l’adoption. Les référents sécurité doivent donc faire partie des équipes d’ingénierie, et non se trouver à l’extérieur. Ce sont eux qui font réellement avancer la sécurité. »

Rinki Sethi, VP et CISO chez Bill.com

La documentation joue également un rôle essentiel dans l’adoption par les développeurs. Elle est souvent rédigée par des développeurs et présente leur expérience : conseils d’utilisation, explications des décisions et nuances. L’équipe de sécurité peut contribuer à sa création, mais aussi aider à coordonner et à partager cette documentation avec d’autres équipes qui adoptent des pratiques, des processus ou des outils similaires. Offrir aux équipes de développement une expérience en libre-service de qualité, comme elles en attendent des outils de développement, est un élément clé d’une adoption réussie.

Comment définir les règles de sécurité et les décisions de processus dans les workflows de développement ?

Le degré d’autonomie se mesure notamment à la marge de manœuvre dont dispose un développeur ou une équipe pour définir ses processus et les tests de ses pipelines. Il est normal que les règles et les politiques de sécurité soient élaborées avec la contribution de l’équipe de sécurité, puis communiquées aux équipes de développement, qui s’appuient sur ses conseils pour les intégrer à leurs processus existants et déployer des formations efficaces. L’essentiel réside dans la manière dont ces règles sont déployées et mises en œuvre. Les équipes de développement doivent pouvoir s’approprier leurs workflows, prendre des décisions et les modifier comme elles le souhaitent. Cela ne signifie pas que chaque équipe doit adopter une approche personnalisée : il est essentiel qu’elles apprennent les bonnes pratiques les unes des autres. Elles doivent pouvoir prendre des décisions en s’appuyant sur les conseils d’autres équipes de développement et du groupe de sécurité, afin que les solutions mises en place répondent aux exigences et aux normes de l’équipe de sécurité.

Cette approche présente notamment l’avantage de favoriser une dynamique positive. Tout d’abord, en évitant d’imposer une pratique ou un processus à l’équipe de développement, vous pouvez, en tant que spécialiste de la sécurité, travailler avec elle pour résoudre un problème ou répondre à une exigence de sécurité. Vous évitez ainsi la résistance naturelle que suscite une décision imposée de l’extérieur. En adoptant un rôle de conseil, l’équipe de sécurité apporte un soutien que les équipes de développement accueillent souvent plus favorablement pour prendre les bonnes décisions.

Au final, tout se résume à la question de la responsabilité. Si vous demandez à votre équipe de sécurité d’assumer la sécurité du code écrit par les équipes de développement, vous lui demandez d’étendre considérablement ses services à toute l’organisation, au risque d’en faire un goulot d’étranglement. Traditionnellement, les équipes de sécurité ont tendance à imposer des exigences aux équipes de développement, souvent sans mandat, ce qui leur vaut d’être perçues comme des obstacles.

Si vous devez restreindre les technologies ou les piles technologiques que l’équipe de développement peut utiliser, il est important de proposer une voie balisée avec plusieurs options bien prises en charge par les équipes de sécurité et les autres équipes. Par exemple, il est courant de mettre à disposition un ensemble d’images de conteneurs de référence, entièrement testées par les équipes de sécurité et les autres équipes, que les développeurs peuvent choisir et enrichir. En proposant des options qui constituent aussi une voie balisée, vous ne serez pas perçu comme un obstacle et aiderez les équipes à rester en sécurité.

Visibilité et transparence entre les équipes

Avoir une vue d’ensemble de la posture de sécurité de vos applications, pipelines et processus est la première étape pour repérer les risques et l’exposition de vos équipes et de votre entreprise. Cependant, si vous n’agissez pas en fonction des résultats, cette visibilité ne sert à rien. Au cours de cette étude, nous avons constaté que synthétiser régulièrement la posture de sécurité sous la forme d’un tableau de bord de responsabilisation ou d’un rapport était l’un des facteurs déterminants d’une adoption réussie par les développeurs.

Les tableaux de bord des entreprises ayant obtenu les meilleurs résultats en matière d’adoption couvraient la sécurité, mais aussi de nombreux autres aspects : travail sur les fonctionnalités, fiabilité, performances, etc. Générés chaque mois, ils présentaient des indicateurs opérationnels comme le nombre de vulnérabilités, l’adoption des outils de sécurité, les métriques de tests des projets, le niveau de formation, et bien plus encore. Point essentiel, les indicateurs choisis par chaque entreprise étaient alignés sur ses objectifs métier. Voyons plus en détail comment ces tableaux de bord étaient utilisés.

Priorisation et justification

Avec une grille d’évaluation qui couvre les indicateurs métier, y compris la sécurité, il est facile de voir si la sécurité est la priorité du moment ou s’il existe ailleurs des problèmes plus urgents à traiter. Il est important d’évaluer d’autres aspects que la sécurité : pour prendre des décisions éclairées, il faut disposer de toutes les données.

Les grilles d’évaluation doivent être établies à différents niveaux, avec des données adaptées aux personnes qui les consultent. Par exemple, un dirigeant voudra moins de détails qu’un responsable d’équipe, mais souhaitera davantage voir le lien avec les objectifs globaux de l’entreprise. Les dirigeants peuvent ajuster leurs priorités en fonction des résultats du rapport, qui montre les domaines dans lesquels l’entreprise doit concentrer davantage ses efforts. Une équipe, en revanche, voudra savoir où consacrer plus de temps et comment ses résultats se comparent à ceux du reste de l’organisation.

Toutes ces données permettent aux développeurs et aux équipes de mieux hiérarchiser les tâches à accomplir lors des prochains sprints et de justifier ces choix. Si quelqu’un demande pourquoi la sécurité fait l’objet d’une attention particulière, il est important de présenter une grille d’évaluation objective plutôt qu’une explication subjective.

Dans le cadre de ces grilles d’évaluation, l’équipe de sécurité doit également formuler des recommandations concrètes de priorisation à l’intention de l’équipe de développement. Elle peut, par exemple, mettre en avant les principales vulnérabilités (ou catégories de vulnérabilités) à traiter pour obtenir le plus grand impact.

Responsabilisation

Pour que la sécurité soit une priorité, chacun doit rendre des comptes, du haut en bas de la hiérarchie. Le CTO répond devant le CEO, les vice-présidents de l’ingénierie devant les CTO, les responsables devant les vice-présidents, et ainsi de suite jusqu’aux ingénieurs. Lorsque chacun a une raison de se soucier de la sécurité, celle-ci devient naturellement une composante essentielle de tous les rôles.

Heureusement, les grilles d’évaluation sont un moyen simple et efficace de responsabiliser les bonnes personnes quant aux exigences qui leur incombent. En les publiant, chacun au sein de l’organisation peut rapidement voir où les résultats sont dans le rouge ou évoluent dans la bonne direction. Lorsque les seuils définis sont atteints, les personnes responsables d’indicateurs spécifiques peuvent en déterminer les causes, les justifications et les solutions possibles.

Comme nous l’avons constaté pour la priorisation de la sécurité, la responsabilisation en matière de sécurité doit véritablement s’appliquer jusqu’au sommet. Dans le cas contraire, le message selon lequel elle est importante pour l’entreprise (et doit donc l’être pour l’équipe de développement) perd considérablement de sa force, et l’adhésion disparaît.

Misez sur les valeurs des développeurs et la gamification

En règle générale, les développeurs tiennent à livrer des applications qui fonctionnent, mais qui sont aussi rapides, fiables et sécurisées. De nombreux obstacles peuvent les empêcher de produire du code conforme à leurs exigences, mais ils sont fiers de ce qu’ils livrent. Les grilles d’évaluation sont un excellent moyen de gamifier cette volonté de produire le meilleur code possible et de passer d’une responsabilisation fondée sur la sanction à une approche fondée sur l’encouragement.

Donner à vos équipes de développement une visibilité sur l’état de leurs projets est un bon moyen de leur montrer leurs progrès et leurs points forts, mais aussi les difficultés qu’elles rencontrent ou les retards qu’elles accumulent. Un développeur ou une équipe de développement peut perdre sa fierté en constatant que sa grille d’évaluation est la moins bonne du service ou nettement inférieure à la moyenne de son unité opérationnelle ou de l’entreprise dans son ensemble. Il voudra naturellement améliorer la situation, mais encore faut-il qu’il en ait conscience.

La gamification est efficace lorsqu’elle est bien mise en œuvre. La façon de procéder dépendra en grande partie de la culture de votre entreprise, mais partager les grilles d’évaluation entre les équipes et leur donner de la visibilité encourage la compétition. Personne ne veut être la moins bonne équipe, et chacun aime voir sa grille d’évaluation progresser et dépasser la moyenne de son équipe — voire figurer parmi les meilleures du service. Il est tout aussi important de partager les idées et les réussites par le biais d’annonces et de discussions. Cela suscite de nouvelles initiatives au sein des équipes, qui cherchent à reproduire ces idées ou à les faire évoluer dans leur propre domaine.