Comprendre les équipes de développement

La mise en place de tout programme transversal exige de l’empathie. Les collaborations entre les équipes de sécurité et de développement échouent souvent en raison de perspectives et d’objectifs très différents. Même si les deux équipes visent le même résultat — des applications sécurisées —, leurs méthodes de travail et leurs critères de réussite peuvent être très différents. Heureusement, l’empathie peut favoriser l’alignement.

Pour obtenir une adoption forte et naturelle, il est important de créer une culture collaborative dans laquelle les équipes de sécurité et de développement parlent le même langage et travaillent ensemble à la réalisation d’objectifs communs. L’équipe de sécurité n’est plus là pour auditer les équipes d’ingénierie et leur donner davantage de travail. Elle est là pour aider les ingénieurs à repérer et à résoudre les problèmes de sécurité le plus tôt, le plus rapidement et le plus efficacement possible. Les équipes d’ingénierie doivent voir l’équipe de sécurité comme un groupe qui leur donne les moyens d’y parvenir, et elles doivent solliciter son aide si ce n’est pas le cas.

Lors du déploiement d’un programme AppSec moderne, il est essentiel que les personnes qui interagissent avec les équipes de développement et les accompagnent comprennent clairement les problèmes, les frictions et les frustrations auxquelles les développeurs sont actuellement confrontés. Ce n’est qu’en les comprenant qu’elles pourront voir comment intégrer la sécurité au processus de développement. Examinons de plus près les aspects à évaluer et à prendre en compte avant de lancer de nouvelles collaborations. Voici quelques questions à vous poser avant de commencer le déploiement.

« La sécurité doit reposer sur un partenariat. Si beaucoup de nos initiatives de sécurité échouent, c’est essentiellement parce que nous essayons d’imposer nos décisions aux équipes que nous voulons aider à réussir, au lieu de nouer un véritable partenariat avec elles. Mon rôle consiste à aider nos équipes d’ingénierie chez Mandiant à produire rapidement du code de qualité, sécurisé et fonctionnel. Notre entreprise doit avancer vite. Le partenariat nous permet de créer des solutions qui répondent aux besoins de l’entreprise et aux exigences de sécurité. »

Tim Crothers, vice-président senior et directeur de la sécurité chez Mandiant

Dans quelle mesure faites-vous preuve d’empathie et de compréhension envers vos équipes de développement ?

Il est essentiel de comprendre comment vos équipes de développement travaillent et prennent leurs décisions. En connaissant leur approche générale et leur niveau de maturité en développement, vous pouvez définir des attentes réalistes, déterminer ce qu’elles peuvent réellement changer et dans quels domaines, et voir comment les aider et leur donner les moyens d’agir au mieux. Sans cela, vous ne pourrez pas comprendre leur point de vue, ce qui créera des frictions et réduira vos chances de réussite. N’oubliez pas non plus que les réponses aux questions suivantes peuvent varier d’une équipe à l’autre au sein d’une même unité opérationnelle, voire d’un même service. Évitez les suppositions et tenez compte des différences de culture et d’approche entre les équipes de développement.

Dans quelle mesure sont-elles prêtes à changer ?

Certaines équipes de développement sont attirées par les dernières technologies — parfois un peu trop — et sont prêtes à essayer de nouveaux outils, technologies, bibliothèques, modèles de programmation, etc., simplement pour rester à la pointe ou voir si une solution ne serait pas meilleure. D’autres équipes ne changent que lorsqu’elles rencontrent un problème ou sont certaines que le changement résoudra un problème qui touche actuellement leur application. Enfin, certaines équipes évitent par défaut tout changement, selon le principe : « Si ce n’est pas cassé, ne le réparez pas. »

Comprendre le comportement et l’état d’esprit de vos équipes de développement face au changement vous aidera à déterminer la meilleure façon de collaborer avec elles pour définir un objectif commun ou une cible pour votre programme AppSec. Par exemple, si elles ont déjà refusé d’effectuer des tests via des pull requests (PR) Git, ne partez pas du principe que l’ajout de tests de sécurité dans leurs PR donnera des résultats différents des tentatives précédentes.

Pour évaluer la maturité et la capacité d’adaptation de vos équipes de développement, il est important de distinguer l’adoption technique de l’adoption des processus. Les entreprises moins matures ou en phase de démarrage accordent souvent davantage d’importance à l’adoption technique qu’à la normalisation des processus. Par exemple, les startups doivent publier rapidement pour être les premières sur le marché, ce qui relègue la maturation des processus et des normes au bas de leurs priorités. Il sera très difficile de convaincre une entreprise à ce stade de mettre en œuvre une pratique de sécurité qui fait office de contrôle bloquant.

Dans quelle mesure l’équipe ou les projets sont-ils bien définis ?

La propriété des ressources est l’une des principales différences entre le point de vue de l’équipe de sécurité et celui des développeurs. Du point de vue de l’équipe de sécurité, les équipes d’ingénierie possèdent un certain nombre de ressources, dont certaines sont plus critiques que d’autres. Du point de vue des développeurs, chaque équipe se concentre sur un ensemble de projets ou de services dont elle est responsable, contribue à des projets appartenant à d’autres équipes, et participe aussi à des projets utilisés et indispensables à de nombreuses équipes, mais qui ne relèvent d’aucune équipe en particulier.

Ainsi, demander à une équipe de développement d’assumer la sécurité de son code et de ses projets donnera des résultats variables selon la propriété de chaque projet. Plus le périmètre est clairement défini, plus l’équipe de développement sera susceptible d’assumer la responsabilité de la sécurité du projet.

L’ancienneté de l’équipe peut également influencer votre approche du déploiement. Idéalement, les normes et les processus peuvent être instaurés dès la création d’une nouvelle équipe. Mais il est plus probable que vous deviez tirer parti des changements naturels. Par exemple, si une équipe connaît un changement majeur sans lien avec votre programme (nouveau responsable, réorganisation de l’équipe, etc.), elle sera plus susceptible d’adopter de nouvelles normes de développement dans le cadre de la définition de ses méthodes de travail.

Quelle est la capacité actuelle de votre équipe ?

Comme la plupart des équipes, les développeurs ne restent pas sans rien faire en attendant que le travail arrive. Ils définissent leurs priorités, tout en sachant pertinemment qu’ils ne pourront pas venir à bout de leur liste de tâches, qui ne cesse de s’allonger. Ajouter simplement des tâches à la charge déjà excessive d’un développeur ou d’une équipe n’est ni constructif ni aidant. La situation est encore plus difficile pour les équipes en sous-effectif, qui font de leur mieux pour enchaîner les sprints tout en essayant de garder la tête hors de l’eau.

« Nous savons qu’ils ont beaucoup d’autres responsabilités. Ils doivent créer des fonctionnalités et des produits. Ils doivent aussi se soucier des performances et de la fiabilité. Nous voulons rendre leur participation à la sécurité aussi simple que possible. »

Jason Chan, vice-président de la sécurité chez Netflix

Quelle est l’étendue des compétences des équipes au sein de l’organisation ?

Il est important de prendre le temps de comprendre la dynamique de vos équipes de développement, car elles sont toutes différentes. Il est très fréquent qu’un petit nombre d’équipes pionnières adoptent en premier les nouvelles technologies et les nouveaux processus, puis que le reste de l’organisation les suive progressivement. L’adoption par la majorité démarre généralement lentement, puis s’accélère lorsque suffisamment d’automatisations et de bonnes pratiques sont en place pour faciliter l’adoption par les autres équipes. Bien sûr, abaisser considérablement les obstacles pour permettre une adoption à grande échelle signifie que de nombreuses équipes mettront beaucoup plus de temps à adopter ces pratiques, si elles le font. Avant de favoriser leur adoption par les développeurs, vous devez savoir combien d’équipes auront besoin d’obstacles moins importants, et quelles équipes pourront mener des projets pilotes pour créer les automatisations et les pratiques nécessaires.

La diversité des compétences des équipes se manifeste notamment dans leur tendance à ajouter des intégrations et leur volonté de recevoir des retours. En général, les équipes matures souhaitent recevoir des retours le plus tôt possible, dans leur IDE ou grâce à l’automatisation de leurs processus de compilation locaux, mais aussi dans leurs dépôts Git. Les équipes moins matures peuvent préférer limiter l’automatisation au processus CI, et recevoir ainsi des retours tardifs, généralement juste avant un déploiement en production. Il est peu probable que le déploiement auprès de ces deux types d’équipes au sein d’un même groupe soit une réussite. Il risque surtout de submerger les équipes les moins matures.

La complexité et l’ancienneté des projets expliquent souvent les disparités en matière d’adoption. Un service ancien et complexe, en maintenance plutôt qu’en développement actif, est un bon exemple de projet qui ne conviendrait pas, car les changements de processus risquent de susciter davantage de résistance. De même, si votre organisation s’est développée de manière externe (par exemple, par le biais d’acquisitions), vous hériterez de technologies, de pipelines et de cultures différentes. La cohérence à l’échelle de l’organisation s’en trouvera réduite, et le risque que vos suppositions sur les équipes soient erronées augmentera.

Comment vos équipes de développement intègrent-elles aujourd’hui les pratiques de sécurité à leur pipeline ?

Après avoir pris le temps d’évaluer les équipes de développement de votre organisation, il est important de déterminer quelles pratiques de sécurité elles suivent actuellement et comment elles les appliquent, afin de définir un point de départ. Au début, les équipes de développement adoptent généralement une approche très peu contraignante. Elles peuvent, par exemple, exécuter périodiquement des tests destinés uniquement à fournir de la visibilité, et les intégrer au pipeline lorsque c’est possible. Au départ, il n’y aura probablement aucun blocage ni contrôle, ce qui permettra aux équipes de développement de continuer à livrer à la vitesse à laquelle elles sont habituées.

Prenez ensuite note de leurs préférences en matière d’intégration. Effectuent-elles des analyses ou des tests dans le CI, ou plus tôt dans les PR ? Utilisent-elles une intégration prête à l’emploi, ou ont-elles créé des scripts et des automatisations pour l’adapter à leur pipeline ou à leur projet ? Effectuent-elles des tests dans les IDE, ou leur approche est-elle plutôt réactive ? Les équipes qui privilégient l’intégration seront plus susceptibles d’adopter une solution de sécurité intégrée aux outils de développement.

« À mon avis, l’essentiel est de comprendre les pratiques privilégiées par nos équipes d’ingénierie. Quels sont leurs modèles de travail, afin que nous puissions collaborer pour mettre en place des garde-fous plutôt que des contrôles ? Nous voulons soutenir les résultats que les équipes cherchent à obtenir. Nous devons veiller à ce qu’elles appliquent les pratiques et les processus qu’elles ont jugés appropriés. Et généralement, nous collaborons avec elles dans ce sens. Pour résumer, nous cherchons constamment les lacunes : celles de nos processus, celles de notre [collaboration]. »

Tim Crothers, vice-président senior et directeur de la sécurité chez Mandiant

Quelle priorité accordent-elles à la sécurité pendant les sprints ?

Pour savoir où en est une équipe dans son parcours de sécurisation, vous pouvez aussi déterminer si elle concentre davantage ses efforts sur les développements à venir ou sur son backlog. Celui-ci peut être particulièrement volumineux, avec des milliers de problèmes ou de vulnérabilités, alors qu’une nouvelle fonctionnalité ne peut en introduire que quelques-uns. Il est également important de comprendre comment l’équipe trie les problèmes pour déterminer lesquels sont importants (ou doivent absolument être corrigés), ainsi que quand et comment les faire remonter. Si une équipe a défini des OKR pour son backlog et mis en place des processus favorisant les progrès, elle sera plus susceptible d’adopter des outils qui l’aideront à avancer plus vite.

Comment intègrent-elles les tests et les corrections de sécurité à leurs sprints ? Exigent-elles que les tests de sécurité soient concluants avant de livrer le code, ou ajoutent-elles les tâches de sécurité à leur backlog de dette technique et consacrent-elles un sprint tous les quelques mois à la correction des problèmes ? Cette dernière approche est souvent adoptée par les équipes moins matures, voire par certaines équipes peu performantes qui ne parviennent pas à contenir le travail dans les sprints. Dans ces cas, il est tout aussi courant de voir des sprints consacrés à la mise à l’échelle, aux performances ou à la fiabilité, qui se disputent tous du temps avec les sprints dédiés à la sécurité.

Enfin, l’équipe dispose-t-elle d’une documentation interne sur ses méthodes de test ou d’accords de niveau de service (SLA) qu’elle doit respecter pour traiter les problèmes ? Ce sont autant de questions utiles qui vous permettent non seulement de comprendre où en est l’équipe aujourd’hui, mais aussi de déterminer la prochaine étape pour lui faciliter les tests et l’aider à se concentrer sur les bonnes priorités.