7 conseils pour guider les développeurs dans leurs décisions de sécurité
Dans le rapport “Sécurité des applications : état des lieux 2023” de Forrester, 53 % des responsables sécurité interrogés déclarent que le choix final d’une solution de sécurité des applications revient aux équipes de développement.
Seuls 2 % des dirigeants affirment que les développeurs ne sont pas du tout impliqués dans ces décisions. Pour négocier au mieux ce changement de cap, les équipes de sécurité doivent maîtriser un certain nombre de paramètres essentiels pour mieux collaborer avec les développeurs.
1. Le soutien doit être réciproque
Ce nouveau pouvoir décisionnel est une réelle aubaine pour les développeurs. Mais en tant que professionnel de sécurité, votre rôle est de leur faire comprendre les nouvelles responsabilités qu’ils devront assumer en retour.
Les équipes de développement peuvent saisir cette chance pour choisir des outils qui facilitent leur travail, accélèrent leurs processus et s’intègrent parfaitement à leurs workflows actuels. Mais cela signifie qu’elles devront aussi mieux maîtriser les principes et pratiques de sécurité – un domaine jusqu’ici réservé à des équipes de sécurité spécialisées.
Par ailleurs, le rôle des professionnels de sécurité évolue également. Leur mission ne consiste plus seulement à appliquer les bonnes pratiques de sécurité, mais aussi à aider les développeurs à prendre les bonnes décisions. Il sera donc nécessaire de faire preuve de pédagogie et d’expliquer à ces équipes comment évaluer et implémenter efficacement les outils et technologies de sécurité disponibles.
2. Identifiez vos « champions de la sécurité » parmi les développeurs
Repérer des « champions de la sécurité » ou, tout du moins, des développeurs qui expriment un réel intérêt pour la question constitue la première étape d’une stratégie efficace. La cybersécurité est une discipline qui évolue constamment au gré des nouvelles menaces. Certains développeurs trouvent cela fascinant : il convient de dénicher ces talents et de les former en priorité.
À l’inverse, certains développeurs ne se sentent pas vraiment concernés par ces enjeux.
Les champions de la sécurité ont ici un rôle essentiel à jouer, car il leur incombera de traduire le jargon complexe de la cybersécurité en des termes plus concrets pour leurs pairs.
Lire aussi : PaaS et multicloud, une antinomie ?
3. Le DevSecOps demande de l’application et de l’engagement
Depuis son apparition, le DevSecOps nourrit des débats parmi les professionnels de sécurité, y compris quant à la définition même du concept. D’aucuns mettent en doute sa nécessité, arguant que la sécurité fait depuis toujours partie du DevOps, alors que d’autres la considèrent comme un bon moyen de souligner l’importance de la sécurité dans le DevOps.
Toujours est-il que pour bon nombre de développeurs, le « DevSecOps » n’est qu’un énième concept creux qui ne fait qu’alourdir une charge de travail déjà bien pesante. En résumé, le DevSecOps a pour but d’intégrer les pratiques de sécurité dans toutes les phases du cycle de développement logiciel, notamment en amont. L’objectif est ici de détecter et prévenir les vulnérabilités le plus tôt possible, ce qui en théorie peut faire gagner beaucoup de temps et éviter bien des crispations.
Dès lors qu’on le pratique dans les règles de l’art, le DevSecOps a un effet rassembleur sur les équipes. Mais, premièrement, cela requiert une transformation au niveau de la structure organisationnelle, avec des mesures de sécurité appliquées et priorisées au niveau de la direction. Deuxièmement, vous devez convaincre les développeurs.
4. Posez les bonnes questions pour vous aider mutuellement à trouver les bons outils
Les outils de sécurité applicative doivent s’intégrer parfaitement au workflow de développement et fournir des résultats précis, sans perturber le travail des développeurs.
D’où l’importance de leur poser les bonnes questions pour obtenir des réponses constructives dans le cadre d’un processus d’achat de technologies. Qu’attendent-ils d’un outil de sécurité ? Doit-il s’intégrer à GitHub ? Doit-il proposer des fonctionnalités d’analyse pour Java et Python ? Des notifications sur Slack ou Jira ?
En établissant clairement le cahier des charges, vous mettrez toutes les chances de votre côté pour trouver les solutions adaptées. En tant que professionnel de sécurité, il est fort probable que vous ayez une meilleure connaissance des différentes technologies disponibles sur le marché.
5. Comprenez les motivations profondes des développeurs
Chacun sait que les objectifs des équipes de sécurité et de développement sont souvent très différents. Mais même au sein des équipes DevOps, les motivations individuelles des développeurs se distinguent aussi parfois de celles de leurs managers.
Le but global de l’équipe est peut-être de livrer du code le plus rapidement possible. Mais au quotidien, ce n’est pas nécessairement ce qui anime les développeurs, qui aiment avant tout créer des choses et résoudre des problèmes. Leur travail ne se limite pas à écrire des lignes de code : ils réfléchissent aux meilleurs moyens de créer des produits porteurs d’un maximum de valeur pour l’entreprise.
Lire aussi : IaaS : Google, plus "visionnaire" que les autres ?
6. Trouvez des objectifs et des indicateurs communs
Les équipes de sécurité et de développement doivent s’entendre autour de métriques et d’objectifs partagés. Il s’agit ici de synchroniser leurs actions respectives, en établissant des objectifs réalistes et mutuellement bénéfiques.
Par exemple, aucun des deux groupes n’a envie d’être confronté à une panne ou une interruption de service. C’est une métrique que tout le monde veut mesurer, mais que personne ne veut voir se matérialiser. De plus, les objectifs fixés doivent être réalistes.
Le code zéro défaut n’existe pas : vous devez donc déterminer un chiffre pragmatique et définir des attentes conformes à la réalité du terrain.
7. Apprenez comment les développeurs travaillent
Les équipes de sécurité doivent se familiariser avec les méthodes de travail des développeurs. Il ne s’agit pas ici d’en maîtriser tous les aspects techniques, mais plutôt de comprendre les processus de build et les problématiques qu’ils soulèvent. Quels sont leurs processus ? Où enregistrent-ils leur code ? Quels outils utilisent-ils actuellement ? Ces petits efforts peuvent faire toute la différence.
Par exemple, j’ai déjà vu des équipes de sécurité aider les équipes de fiabilité des sites à détecter une panne de service et à en comprendre la cause. Votre engagement et votre écoute sont essentiels.
Alexandre Pierrin-Neron, Regional VP EMEA South - Lacework.
Sur le même thème
Voir tous les articles Cybersécurité