Sécurité vs développement : une question de priorités

Dans l’écosystème technologique dynamique d’aujourd’hui, il est essentiel de gérer les programmes AppSec à grande échelle. À mesure que les bases de code s’étendent et que les menaces gagnent en sophistication, l’accent se déplace de la correction de vulnérabilités isolées vers la mise en place d’une posture de sécurité cohérente dans toutes les équipes de développement. Les approches émergentes, comme la gestion de la posture de sécurité des applications (ASPM), permettent aux organisations de dépasser le cadre des vulnérabilités individuelles et de coordonner des programmes complets axés sur la gestion des risques métier critiques. Ces outils simplifient le processus en automatisant les contrôles de sécurité, en améliorant l’analyse des risques et en hiérarchisant les vulnérabilités.

Il convient de noter que, si l’ASPM peut sembler être une approche nouvelle pour certains, chez Snyk, nous avançons dans cette direction depuis 8 ans. Dès le premier jour, Snyk a été un pionnier des outils AppSec « conçus pour les développeurs ». Notre objectif a toujours été d’aller au-delà du simple « déplacement vers la gauche » avec les outils AppSec traditionnels et de faire comprendre aux équipes que, pour être réellement efficace, l’AppSec exige que les entreprises confient davantage de responsabilités en matière de sécurité aux développeurs. Cela nécessitait une toute nouvelle catégorie d’outils de sécurité conçus pour les développeurs.

Même si les responsabilités en matière de sécurité sont confiées aux développeurs, l’équipe de sécurité reste responsable de la posture de risque applicatif de l’entreprise. Intégrer les outils aux outils des développeurs ne représente qu’une partie du travail de Snyk. Une part encore plus importante consiste à aider les équipes de sécurité et de développement à collaborer pour adopter une approche de la sécurité davantage axée sur la prévention. Bien entendu, cela implique d’utiliser les outils de Snyk, mais aussi de proposer des formations et des programmes de champions de la sécurité, de définir et mesurer des indicateurs de réussite AppSec, et de déployer les réussites de la première équipe applicative à toutes les applications et équipes. Fort de l’accompagnement de nos clients au fil des années, l’ASPM témoigne de notre engagement et de la concrétisation de notre expertise cumulée, établissant une référence en matière de sécurité des applications.

Pour exploiter pleinement le potentiel de ces outils, il est essentiel d’aligner stratégiquement les équipes de développement et de sécurité. Cet alignement représente souvent un défi, car ces équipes peuvent parfois sembler évoluer dans des univers distincts. Compte tenu des avantages de l’ASPM, il est d’autant plus important de comprendre les motivations propres à chaque équipe.

Comprendre les motivations propres à chaque équipe est essentiel pour favoriser une adoption généralisée des outils de sécurité par les développeurs, comme Snyk.

Besoins des équipes

Les points de friction

• Priorités : correctifs de sécurité indispensables ou nouvelles fonctionnalités essentielles.

• Rythme : prudence de l’équipe de sécurité ou sprints de l’équipe de développement.

• Adoption des outils : l’enthousiasme des développeurs pour de nouveaux outils peut contourner le processus de validation de la sécurité.

• Communication : les deux équipes ne parlent pas toujours le même langage : la documentation de l’une peut sembler incompréhensible à l’autre.

• Formation : les développeurs peuvent percevoir la formation à la sécurité comme un détour.

Prendre du recul : repérer le manque d’alignement

Pour résoudre les éventuels problèmes d’adoption des outils de sécurité par les développeurs, commencez par diagnostiquer tout manque d’alignement existant :

Questions que les responsables de la sécurité peuvent se poser

• Stratégie : quelle place les développeurs occupent-ils dans notre vision de la sécurité ?

• Outils : comment aidons-nous les développeurs à intégrer la sécurité ?

• Formation : quel est notre plan de sensibilisation des développeurs à la sécurité ?

• Boucle de rétroaction : comment se passe la communication entre les développeurs et l’équipe de sécurité ?

Questions que les responsables de l’ingénierie peuvent se poser

• Point de vue des développeurs : comment les développeurs perçoivent-ils leur rôle en matière de sécurité ?

• Défis : quels obstacles rencontrent-ils avec les outils de sécurité destinés aux développeurs ?

• Relations entre sécurité et développement : comment définiriez-vous la relation actuelle entre ces deux équipes ?

• Tirer les leçons des erreurs : après un incident de sécurité, comment les enseignements sont-ils intégrés ?

• Répartition des sprints : quel pourcentage de nos sprints consacrons-nous à la sécurité ?

Créer une synergie : favoriser l’adoption des outils de sécurité par les développeurs

Une fois le manque d’alignement repéré, il s’agit de bâtir un pont entre les équipes :

Dialogue

• Responsable de la sécurité : échangez régulièrement avec les développeurs sur les actualités de sécurité et restez à l’écoute de leurs retours.  

  • Hiérarchiser les mises à jour essentielles : les échanges réguliers sont indispensables, mais il importe aussi de distinguer les notifications de sécurité critiques des alertes moins importantes afin de ne pas submerger les développeurs.

  • Se réunir régulièrement : organisez des réunions mensuelles ou trimestrielles avec les développeurs pour partager des informations sur la sécurité et discuter des tendances plutôt que d’incidents isolés.

• Responsable de l’ingénierie : encouragez les développeurs à participer librement à ces échanges. Désignez un interlocuteur qui pourra travailler directement avec le fournisseur des outils de sécurité.

Intégration fluide

• Responsable de la sécurité : intégrer les contrôles de sécurité aux outils SCM et/ou aux pipelines CI/CD est un bon début. Assurez-vous que les données de sécurité sont visibles et exploitables. Au départ, ne faites pas échouer les contrôles de sécurité des PR ni les builds : privilégiez la sensibilisation pour instaurer la confiance des développeurs plutôt que la contrainte.

• Responsable de l’ingénierie : donnez aux développeurs les connaissances nécessaires pour utiliser les outils de sécurité. Coordonnez les alertes de vulnérabilité, leur triage et la définition des politiques.

Apprentissage continu

• Responsable de la sécurité : exploitez les outils de sécurité destinés aux développeurs pour organiser des ateliers ciblés.

• Responsable de l’ingénierie : encouragez les développeurs à participer aux ateliers lorsque les sujets abordés concernent directement leur travail.  Faites régulièrement part de vos retours à l’équipe de sécurité sur les sessions afin qu’elles restent intéressantes et adaptées aux développeurs.

Indicateurs communs

• Responsable de la sécurité :  mettez en place des indicateurs clés de performance liés aux vulnérabilités. Partagez les résultats, célébrez les réussites et restez à l’écoute des retours des développeurs.

• Responsable de l’ingénierie : consacrez une partie du budget de réduction de la dette technique à la sécurité en réservant un pourcentage des sprints à la correction des problèmes existants. Intégrez des objectifs de sécurité à la planification des sprints, en particulier lors du lancement de nouvelles fonctionnalités.  Encouragez les développeurs à faire régulièrement part de leurs retours sur les alertes de sécurité, en distinguant les problèmes critiques du bruit de fond.

Hiérarchiser les priorités pour rester en sécurité

En conclusion, pour optimiser les programmes AppSec à grande échelle, nous devons aller au-delà de la seule correction des vulnérabilités individuelles et mettre en place des stratégies de sécurité intégrées à toutes les initiatives de développement. Comprendre les motivations propres aux développeurs et aux équipes de sécurité est essentiel à cette démarche.

Des plateformes comme Snyk peuvent catalyser la collaboration entre les équipes de sécurité et de développement grâce à une visibilité accrue, des contrôles de sécurité, une analyse approfondie des risques et une hiérarchisation stratégique des priorités. Cette approche collective est l’avenir : la sécurité ne se contente plus de détecter les menaces, elle collabore avec les développeurs pour concevoir des défenses proactives et créer un écosystème technologique unifié, agile et sécurisé.