3 conseils pour une formation efficace des développeurs à la sécurité

« Nous vivons l’âge d’or de la sécurité des applications », affirme Jim Manico, fondateur de Manicode Security et formateur en codage sécurisé, dans l’épisode 26 de The Secure Developer.

Il y a dix ans, explique Manico, les formations à la sécurité étaient « une activité un peu marginale, qu’on faisait en parallèle ». Aujourd’hui, les outils d’évaluation sont matures, les ouvrages de qualité sur l’évaluation rendent les connaissances plus accessibles et de nombreuses personnes compétentes conçoivent des applications sécurisées.

Vivre l’âge d’or ne signifie pas que le problème de la sécurité est résolu. Cela signifie plutôt que nous savons ce qu’il faut apprendre et que nous disposons des ressources et de la volonté nécessaires pour transmettre ces connaissances.

Dans cet article, nous vous proposons trois conseils pour améliorer votre programme de sensibilisation des développeurs à la sécurité et profiter pleinement de l’âge d’or de la sécurité des applications.

1. Facilitez l’apprentissage en définissant clairement les exigences de sécurité

La sensibilisation des développeurs à la sécurité est impossible sans une compréhension claire et partagée de la sécurité des applications.

C’est pourquoi, selon Manico, définir clairement les exigences de sécurité est l’une des mesures les plus importantes que les entreprises puissent prendre pour sensibiliser leurs développeurs. « Je veux une définition claire des exigences de sécurité, explique Manico, afin que nous soyons tous sur la même longueur d’onde quant à ce que recouvre réellement la sécurité des applications. »

Beaucoup se tourneraient spontanément vers l’OWASP Top 10, mais Manico recommande de l’éviter. Il préconise plutôt la norme OWASP Application Security Verification Standard, qui compte plus de 200 exigences. Selon lui, le grand avantage de cette norme, c’est qu’elle porte ses fruits, quel que soit le degré d’application de l’équipe.

« À un niveau général, explique Manico, nous définissons les exigences, puis nous traduisons chacune d’elles en mesures concrètes : ce qui existe déjà dans le framework, ce que nous devons faire nous-mêmes manuellement et les points pour lesquels des outils tiers peuvent nous aider. »

Mais même si les équipes ne vont pas aussi loin, la démarche reste utile. « J’ai vu des personnes définir des exigences, ne jamais les lire et constater malgré tout que le processus était utile, car les responsables techniques ont pu consacrer quatre ou cinq heures à expliquer aux développeurs principaux les enjeux de sécurité », raconte Manico.

L’examen des exigences de sécurité permet donc aux développeurs et aux équipes de sécurité de s’entendre sur les mesures nécessaires pour atteindre un certain niveau de sécurité des applications. Même sans aller aussi loin que possible, parvenir à un consensus peut déjà beaucoup aider.

« Quelle que soit la manière dont vous les déployez, elles seront utiles d’une façon ou d’une autre », affirme Manico.

2. Rendez les équipes de développement autonomes grâce à un référent sécurité

Les cérémonies de remise des diplômes font verser des larmes dans les lycées et les universités, alors même que l’obtention du diplôme est l’objectif. En fin de compte, malgré l’émotion, tout enseignant souhaite voir ses élèves devenir indépendants, autonomes et accomplis.

Il en va de même pour la sensibilisation des développeurs à la sécurité. Les entreprises ont raison de faire appel à des consultants et formateurs externes en sécurité, mais elles ont intérêt à choisir des personnes qui anticipent la façon dont les équipes fonctionneront une fois leur mission terminée.

Nick Vinson, responsable DevSecOps chez Pearson, applique cette approche. Dans l’épisode 84 de The Secure Developer, il explique que l’objectif principal de son travail est de « fournir à l’équipe les outils et les connaissances dont elle a besoin pour être autonome ».

Pour cela, l’équipe de Vinson intègre des ingénieurs sécurité expérimentés aux équipes qu’elle accompagne. Ces ingénieurs contribuent pleinement au travail de l’équipe et peuvent apporter, tester et déployer des modifications en production.

Au sein de l’équipe, ces experts intégrés réalisent des modélisations des menaces afin d’identifier les risques de sécurité et les vulnérabilités. Ils mettent aussi en place des tests de sécurité automatisés dans le cycle de développement logiciel (SDLC), tout en veillant, comme le souligne Vinson, à ce que « les équipes sachent quoi faire, au lieu de se contenter de cocher des cases ».

Pour ancrer ces nouvelles connaissances, l’expert intégré forme également un référent sécurité interne, en plus de fournir du travail et des conseils. « C’est notre principale responsabilité », affirme Vinson.

En intégrant un ingénieur sécurité, Vinson atteint deux objectifs en parallèle : renforcer plus rapidement la sécurité des applications et former un référent sécurité capable d’inscrire ces pratiques de codage sécurisé dans la durée.

3. Gagnez la confiance des développeurs en établissant votre crédibilité

Beaucoup doutent de l’efficacité de la sensibilisation des développeurs à la sécurité. Les développeurs ne vont-ils pas simplement considérer la sécurité comme une formalité à cocher, qui les détourne de leur travail principal ?

Jet Anderson, ingénieur sécurité chez Amazon, réagit sans détour dans l’épisode 98 de The Secure Developer : « C’est des conneries, je ne pense pas que ce soit vrai, pas du tout. »

À l’encontre de ces idées reçues, Anderson constate que les développeurs se passionnent pour la sécurité. « Je trouve que les développeurs sont très attachés à la qualité et qu’ils veulent faire ce qu’il faut », affirme-t-il. Et la sécurité fait pleinement partie du travail bien fait.

Selon Anderson, le fossé entre les développeurs et les ingénieurs sécurité ne s’explique pas par l’indifférence des développeurs, mais par un manque de compréhension mutuelle.

« Ce n’est pas que les développeurs s’en moquent, explique Anderson. C’est que les spécialistes de la sécurité informatique ne maîtrisent pas forcément les subtilités du développement logiciel ; ils peuvent donc manquer de crédibilité, voire de vocabulaire, pour expliquer précisément le risque ou le défaut. »

Anderson prend le terme « vulnérabilité » comme exemple. Courant chez les spécialistes de la sécurité informatique et employé dans différents contextes, ce terme n’est pas toujours celui que les développeurs comprennent le mieux. Selon Anderson, ce que les spécialistes de la sécurité détectent est souvent mieux décrit comme un défaut ; un défaut ne devrait être qualifié de vulnérabilité que lorsqu’un exploit a été trouvé.

« Ces petites nuances font partie du changement de culture », explique Anderson. Même si elles semblent mineures, des évolutions du vocabulaire répétées dans de nombreux contextes peuvent multiplier les occasions de parvenir à une compréhension commune entre ingénieurs sécurité et développeurs. Une fois cette compréhension établie, la sensibilisation des développeurs peut être bien plus efficace.

Intégrer la sécurité plus tôt dans la réflexion des développeurs

Le shift left consiste à déplacer la sécurité, traditionnellement prise en compte à la fin du cycle de développement logiciel (SDLC), vers la gauche, c’est-à-dire plus tôt dans le cycle. Mais selon Anderson, on peut aller encore plus à gauche, avant même la première étape du SDLC. « Je ne vois pas d’étape plus en amont dans le SDLC que le cerveau d’un développeur », affirme-t-il.

Les organisations qui veulent appliquer le shift left et intégrer la sécurité dès la conception fondamentale des applications doivent comprendre à la fois les enjeux et leur point de départ. De nombreux développeurs peuvent obtenir leur diplôme universitaire ou une certification sans avoir rien appris sur la sécurité. Si vous voulez déplacer la sécurité plus en amont, la sensibilisation des développeurs est essentielle.

Abonnez-vous dès aujourd’hui au podcast The Secure Developer pour recevoir d’autres conseils d’experts en sécurité.