Table ronde Snyk et Intuit : briser les silos et mobiliser les communautés de la sécurité et du développement

J’ai récemment participé à une table ronde Snyk avec Intuit. La discussion était si intéressante que j’ai eu envie d’en partager quelques réflexions et enseignements dans un article — en commençant par cette excellente illustration de la session ! Pour résumer, voici les principaux enseignements que j’en ai tirés :

• Présentez les tâches liées à la sécurité aux développeurs comme un moyen de les aider dans leur travail, par exemple en évitant les reprises.

• Faites en sorte que la correction soit la solution la plus simple pour les développeurs, grâce à des outils qu’ils ont envie d’utiliser.

• N’essayez pas de faire de chaque développeur un expert en sécurité : concentrez-vous sur ceux qui souhaitent en apprendre davantage.

• La participation à un programme de Security Champions doit être volontaire. Récompenses, reconnaissance et avantages doivent favoriser la croissance naturelle de la communauté.

• Mesurez les réussites plutôt que l’absence d’infractions.

• Partagez les réussites concrètes des équipes qui font du bon travail pour en inspirer d’autres.

La sécurité intéresse-t-elle vraiment les développeurs ?

La discussion a commencé par une affirmation percutante : les développeurs se soucient rarement de la sécurité. Elle est souvent perçue comme une charge de travail supplémentaire, sans la reconnaissance que l’on pourrait obtenir en livrant une fonctionnalité, par exemple. Bien sûr, cela ne signifie pas que les développeurs ne veulent pas faire ce qu’il faut : la plupart du temps, c’est le cas. Mais comment rendre la sécurité plus attrayante ?

La terminologie employée est un autre facteur qui peut détourner les développeurs de la sécurité. L’utilisation de termes obscurs comme SCA, SAST, DAST ou RASP — que le développeur moyen n’a jamais entendus — peut compliquer les choses et semer la confusion. Il est important d’expliquer ces sigles de trois ou quatre lettres qui ont du sens pour l’équipe de sécurité, afin de les rendre plus accessibles aux développeurs.

Alors, comment rendre la sécurité attrayante pour les développeurs ?

Voici quelques suggestions pour améliorer la sécurité du point de vue des développeurs :

• Présentez-la comme un moyen d’aider les développeurs, par exemple en évitant les reprises.

• Faites en sorte que la correction soit la solution la plus simple.

• Choisissez des outils que les développeurs ont envie d’utiliser.

Éviter les reprises

Une suggestion qui a fait l’unanimité autour de la table consistait à présenter la sécurité d’une façon qui trouve un écho auprès des développeurs. Tous les développeurs détestent devoir refaire leur travail. En faisant de la sécurité un moyen d’éviter ces reprises, on cesse de parler de sécurité pour parler d’activités à réaliser en amont afin d’éviter de longues reprises ultérieures pour corriger des problèmes de sécurité.

Faire de la sécurité la solution la plus simple

Bien sûr, il est essentiel de prévenir les problèmes de sécurité. Leur résolution coûte cher et ils ternissent également un projet, ce que les développeurs préfèrent éviter. Pour prévenir cette réaction, il est essentiel de mettre en place des politiques compréhensibles et une visibilité qui s’intègrent naturellement à la boucle de retour sur la sécurité, afin d’aider les développeurs à éviter les erreurs. Proposez-leur la solution la plus simple, qui les incite à corriger le problème plutôt qu’à l’ignorer.

Des outils pensés pour les développeurs

Bien sûr, les outils jouent également un rôle dans la façon dont les développeurs détectent et corrigent les problèmes de sécurité. Vlad Nikolov, d’Intuit, a notamment expliqué qu’il encourage les développeurs à choisir eux-mêmes leurs outils de sécurité. Les gens veulent avoir le sentiment de contribuer et de s’approprier les outils. Vlad a raconté comment Snyk a été adopté chez Intuit : l’équipe de développement l’a présenté à l’équipe de sécurité comme l’outil qu’elle souhaitait utiliser.

Comment mieux sensibiliser les développeurs ?

Voici quelques réflexions préliminaires importantes à garder à l’esprit :

• La sécurité n’est pas enseignée dans le cadre de la formation au développement logiciel, ce qui constitue un obstacle dès le départ.

• N’essayez pas de faire de chaque développeur un expert : concentrez-vous sur ceux qui souhaitent en apprendre davantage.

Formation à la sécurité

Pour intégrer la sécurité au quotidien des développeurs, elle doit s’ajouter naturellement à leur processus et à leur compréhension du développement logiciel. Il a été observé que les étudiants en école et à l’université n’entendent souvent même pas parler de l’OWASP Top Ten, ni des principes de développement et de conception sécurisés en parallèle de leur formation au développement logiciel. Pour intégrer véritablement la sécurité au processus de développement logiciel, il faut l’enseigner dans le cadre de la formation au développement, afin que les ingénieurs associent le codage sécurisé au développement logiciel en général.

Les équipes ont besoin d’une expertise étendue en sécurité, pas les individus

Mais n’avons-nous pas commencé cette table ronde en disant que les développeurs ne se soucient pas vraiment de la sécurité ? Comment s’assurer que les équipes de développement maîtrisent les pratiques de sécurité si elles n’y pensent pas toujours et ne souhaitent pas forcément les apprendre ? Il est important de distinguer le niveau d’expertise en sécurité nécessaire aux équipes de développement. Les développeurs n’ont pas besoin d’être experts en sécurité, mais ils doivent maîtriser plusieurs domaines, comme la modélisation des menaces. En posant des questions du type « Et si… ? », les développeurs pourront réfléchir aux flux appropriés pour réduire les risques de sécurité.

Stimuler la curiosité grâce à un programme de Security Champions

J’ai retenu deux grands enseignements de cette discussion :

• Consacrez du temps aux développeurs naturellement curieux qui souhaitent en apprendre davantage sur la sécurité.

• La participation à un programme de Security Champions doit être volontaire. Récompenses, reconnaissance et avantages doivent favoriser la croissance naturelle de la communauté.

Transformer la curiosité en expertise

Il faut reconnaître qu’il existe plusieurs profils de développeurs : ceux qui s’intéressent à la sécurité, avec lesquels nous voulons travailler en étroite collaboration, et ceux qui ne s’en préoccupent que par nécessité. Ces derniers feront le strict minimum pour accomplir leurs tâches. Il faut donc maintenir bas le seuil des exigences et simplifier le processus de sécurité. En revanche, nous devons encourager les personnes curieuses de sécurité et tirer parti de leur curiosité, par exemple au moyen d’un programme de Security Champions.

Les Security Champions doivent être bénévoles

Le groupe a convenu que la participation à un programme de Security Champions devait être volontaire. Pour une équipe de sécurité, un tel programme est un excellent moyen de réunir les alliés de la sécurité issus d’équipes de développement dispersées, qui souhaitent s’impliquer. Bien mené, il permettra à de nouvelles personnes de rejoindre progressivement le programme, de leur plein gré, à mesure qu’elles constateront les avantages, les récompenses et la reconnaissance dont bénéficient ses membres.

Célébrer et récompenser les réussites

La célébration des réussites et la récompense des personnes impliquées ont fait l’unanimité. Voici quelques pistes pour y parvenir :

• Mesurez les réussites plutôt que l’absence d’infractions.

• Partagez les réussites concrètes des équipes qui font du bon travail pour en inspirer d’autres.

• Allez au-delà des indicateurs opérationnels et célébrez les réussites, comme l’adoption de processus et d’une posture de sécurité.

Il est juste de constater que la plupart des organisations mesurent la sécurité de leurs projets en fonction des infractions relevées plutôt que des réussites. Cela s’explique en grande partie par le fait qu’il est plus facile de suivre cet indicateur de manière cohérente entre les différentes équipes de développement. Toutefois, cette approche met l’accent sur les problèmes des projets plutôt que sur ce qui a été bien fait. Lorsque tout fonctionne bien, il y a peu de choses à partager avec les communautés de développement au sens large, si ce n’est une diminution du nombre de problèmes.

À l’inverse, nous voulons vraiment parler du nombre de fois où un développeur a détecté et corrigé une vulnérabilité avant qu’elle ne devienne une infraction. C’est un véritable indicateur de réussite d’un programme de sécurité, dont les KPI portent sur des actions qui renforcent la sécurité. En outre, il faut récompenser et transformer ces activités en jeu afin de reconnaître le travail remarquable des développeurs et des équipes qui améliorent leur posture de sécurité, et d’encourager les autres à faire de même.

C’est plus facile à dire qu’à faire. Même s’il était rassurant de constater que tout le monde partageait cette conviction, il était plus difficile de trouver des exemples concrets de mise en œuvre aujourd’hui. Les participants autour de la table souhaitaient notamment faire évoluer notre vocabulaire pour rendre la terminologie plus accessible aux développeurs. Ils voulaient également encourager davantage par des exemples concrets, reconnaître les développeurs qui font un excellent travail pour corriger les vulnérabilités et mettre leur travail en avant, dans l’espoir que d’autres suivent leur exemple et adoptent de meilleurs réflexes de sécurité.

Une réussite ne se mesure pas forcément à l’aide d’un indicateur opérationnel. Elle peut, par exemple, concerner la sécurité intégrée à votre pipeline ou à vos processus. Une idée évoquée consistait à mettre en place un système de notation qui montre où en sont actuellement votre posture de sécurité et celle de votre équipe, ainsi qu’un plan ou une orientation définissant les changements et les améliorations souhaités. Cela permet également de retracer le parcours des personnes et des équipes, et de mesurer leurs progrès.

Comment mesurer l’absence de problèmes de sécurité ?

Il est facile de complexifier à l’excès les KPI et les mesures. L’un des indicateurs importants que nous voulons pouvoir fournir est l’absence de problèmes de sécurité. Pour éviter les reprises lors du développement, nous devons comprendre ce qui a été fait pour les éviter. Mesurer les habitudes en matière de sécurité permet de savoir comment les problèmes sont détectés. Par exemple, les équipes identifient-elles elles-mêmes les menaces de sécurité, notamment grâce à de bonnes pratiques de modélisation des menaces ?

Pour réfléchir à l’impact du shift left, une bonne approche consiste à partir de la droite. À terme, nous voulons que notre environnement de production soit plus sûr, avec moins de risques et de vulnérabilités. Si nous mettons en place des processus et des habitudes en amont, nous verrons les indicateurs et les chiffres diminuer en aval. Cela montrera l’impact et la réussite des activités introduites en amont. Examinez donc vos indicateurs de sécurité, mettez en place une approche de sécurité shift left (pensée pour les développeurs), puis réévaluez vos indicateurs. Découvrez où nous serons prochainement sur https://snyk.io/events/. Pour recevoir une invitation à nos prochaines tables rondes interactives, contactez votre représentant Snyk.