Ne créez pas des outils de sécurité, mais des outils pour les développeurs

Cet article est paru initialement sur CSO Online, le 3 novembre 2017.

Depuis longtemps, les responsables et les fournisseurs de solutions de sécurité applicative poursuivent un objectif difficile à atteindre : faire adopter la sécurité par les développeurs. Cette ambition s’explique en partie par l’intérêt d’intégrer la sécurité dès le départ, mais surtout par le volume de travail et le rythme de développement. Les développeurs sont cent fois plus nombreux que les spécialistes de la sécurité, et la cadence du développement moderne rend impossible pour toute équipe externe de suivre. Pourtant, malgré tous nos efforts, nous n’y parvenons toujours pas.

Les solutions de sécurité s’intègrent aux outils de développement, les exigences de sécurité sont ajoutées au processus habituel de définition des besoins, et les formations à la sécurité sont répétées chaque trimestre. Pourtant, dès que l’équipe de sécurité cesse de s’impliquer, la sécurité est oubliée. Comment sortir de ce cercle vicieux ?

Pour réussir, il faut cesser de créer des outils de sécurité qui tiennent compte du développement et commencer à créer des outils de développement qui intègrent la sécurité. Cela peut sembler être une simple nuance de vocabulaire, mais, en réalité, cela transforme notre façon d’aborder les outils et les programmes de sécurité.

Se concentrer sur les besoins des développeurs

Quand une équipe de sécurité met en place un processus, elle part généralement de ses propres besoins. Elle veut savoir ce que font les développeurs, s’assurer que certains contrôles sont appliqués et imposer l’exécution de certains tests. Il est donc compréhensible que le processus ou les outils visent avant tout à répondre aux besoins de sécurité, de conformité ou de gouvernance, ainsi qu’à ceux de l’équipe de sécurité.

Pour obtenir une véritable adhésion des développeurs, nous devons les considérer comme les principaux utilisateurs de notre solution, et voir la sécurité et la conformité comme des fonctions de soutien. Comment cette pratique de sécurité contribuerait-elle à réduire les risques de panne ? Comment améliorerait-elle la communication et la collaboration au sein de l’équipe ? Comment permettrait-elle aux développeurs moins expérimentés de prendre en charge des tâches plus importantes ? Si vous reformulez les exigences de sécurité en fonction des objectifs des développeurs, vous aurez bien plus de chances qu’elles soient respectées.

Changer de point de départ.

Presque invariablement, nous essayons d’adapter les pratiques de sécurité au processus de développement. Nous tentons d’exécuter l’analyse statique pendant la compilation, avant de constater qu’elle prend trop de temps. Nous intégrons cette analyse à l’IDE, mais ne faisons pas confiance aux développeurs pour écarter les faux positifs des résultats. Nous signalons une vulnérabilité connue à un développeur qui n’a pas les moyens de la qualifier.

Les bons outils pour les développeurs partent de l’autre côté. Comment se déroule le processus de développement ? À quel moment ce contrôle de sécurité serait-il le plus utile ou le moins intrusif ? Quelles sont les principales exigences pour réussir son intégration à ce moment-là ? En répondant à ce type de questions, vous pourrez créer votre solution de sécurité en définissant les bonnes priorités.

Ces questions peuvent aussi révéler des outils déjà utilisés dans le pipeline qui pourraient servir au processus de sécurité. Par exemple, dans deux épisodes distincts du podcast The Secure Developer, l’équipe de sécurité de PagerDuty a expliqué comment utiliser Splunk à des fins de sécurité, et Adam Jacobs, de Chef, a décrit comment InSpec peut améliorer votre posture de sécurité.

Remplacer les produits auxquels vous vous comparez.

Les outils pour les développeurs ont considérablement évolué au cours de la dernière décennie, sous l’impulsion de la révolution DevOps et de l’autonomie accrue des développeurs. Les outils les plus performants ont fait émerger des bonnes pratiques, de la facilité d’utilisation à la tarification, en passant par l’importance de la documentation.

Au lieu de comparer votre pare-feu pour applications Web à votre pare-feu réseau, comparez-le à un outil APM performant (surveillance des performances des applications). Comparez vos outils de test AppSec aux linters et aux outils de revue de code, et non aux scanners de sécurité réseau. Ces outils ont su trouver leur place dans les pratiques des développeurs, qui s’appuient désormais régulièrement sur eux. En vous inspirant de leur fonctionnement, vous vous intégrerez naturellement à la façon de penser et au processus des développeurs.

Mes exemples portent un peu plus sur les outils que sur les processus, mais le principe s’applique aux deux. Les pratiques de développement sécurisé gagneraient tout autant à placer les besoins des développeurs au centre, à partir des méthodologies de développement actuelles et à se comparer aux autres pratiques et processus de l’équipe d’ingénierie. Une pratique de sécurité imposée risque constamment d’être négligée. En revanche, une pratique de développement, même liée à la sécurité, peut s’installer bien plus naturellement.

Pour rallier les développeurs à la sécurité, ne créez pas d’outils de sécurité. Créez des outils pour les développeurs qui contribuent à la sécurité, et constatez à quel point cela change leur adoption.