Le « shift left » ne suffit pas : pourquoi commencer dès le début est la clé de l'excellence en sécurité logicielle

Dans un monde numérique, nous sommes de plus en plus exposés au vol de données. Alors que les grandes organisations agissent comme les gardiens de nos précieuses informations, beaucoup prennent conscience de la nécessité de mettre en œuvre des normes de sécurité rigoureuses.

La plupart des initiatives autour du « shift left », c'est-à-dire l'intégration de la sécurité bien plus tôt dans le processus de développement, ne changent tout simplement pas assez la donne. Cela sous-entend que nous commençons toujours le processus de la mauvaise manière, en faisant marche arrière pour obtenir un logiciel plus sécurisé. Nous devons « commencer à gauche » (start left), en instaurant un changement culturel qui implique positivement les équipes de développement et leur donne les connaissances qui leur manquent actuellement. Cependant, toutes les formations et tous les outils ne se valent pas.

Dans cet article, nous explorons comment les leaders clés, tels que les responsables de la sensibilisation à la sécurité et les directeurs de développement, peuvent véritablement autonomiser leurs développeurs, en faisant d'eux la première ligne de défense contre les cyberattaques coûteuses.

Shift left vs. start left : une distinction importante.

À l'ère des violations de données fréquentes touchant certaines des organisations les plus fiables au monde, les dirigeants d'entreprise se sont tournés vers le secteur de la sécurité pour obtenir des conseils sur la manière d'éviter le désastre financier, réputationnel et opérationnel que représente une attaque réussie.

Pendant longtemps, les spécialistes de l'AppSec (moi y compris) ont conseillé de « passer à gauche » (shift left). Conformément aux meilleures pratiques DevOps, ainsi qu'à de meilleurs résultats en matière de sécurité logicielle, beaucoup d'entre nous ont conseillé d'intégrer la sécurité plus tôt dans le cycle de vie du développement logiciel (SDLC). Il ne devrait pas s'agir de l'étape finale et coûteuse, mais plutôt d'un déplacement vers le début du processus, avec des équipes AppSec impliquées dès la conception des projets logiciels.

Ce n'est pas un mauvais conseil, et c'est certainement mieux que l'ancienne façon de faire (qui, si l'on en croit la quantité de données volées et l'ancienneté des vulnérabilités utilisées pour les dérober, ne fonctionne de toute façon pas). Cependant, si nous commencions réellement à gauche, les résultats en matière de sécurité seraient bien plus positifs.

Shift left, start left... quelle est la différence ? La différence réside dans la manière dont vous impliquez votre équipe de développement. Ils sont véritablement la clé pour fournir des logiciels plus sécurisés, à un coût bien moindre que ce que permettent les chaînes d'outils en fin de cycle et les revues de code manuelles. Dans un monde idéal, chaque développeur écrivant du logiciel disposerait des connaissances et des outils nécessaires pour coder de manière sécurisée dès le départ. Ils repéreraient les failles potentielles, les atténuant avant qu'elles ne soient intégrées (et donc bien plus coûteuses à éliminer et à corriger). Il y aurait une réduction spectaculaire des failles de sécurité que nous observons depuis des décennies, celles qui sont encore responsables de laisser les attaquants entrer par la porte dérobée. Ces fenêtres d'opportunité sous forme d'injections SQL, de cross-site scripting et d'authentifications défaillantes se fermeraient.

Cependant, à l'heure actuelle, l'accent n'est tout simplement pas assez mis sur la sécurité au niveau de la formation professionnelle, et la formation au codage sécurisé sur le lieu de travail varie énormément. Par conséquent, les développeurs disposent rarement de ce dont ils ont besoin pour permettre à une organisation de « commencer à gauche ». Il est temps pour les personnes en position de leadership de collaborer et de plaider pour une sensibilisation plus large à la sécurité, leur connaissance directe et leur contact avec les développeurs étant essentiels pour piloter des programmes efficaces. Après tout, les responsables du développement ont eux-mêmes occupé ces postes, les mains dans le cambouis, dans un domaine de la sécurité souvent difficile à appréhender.

Les développeurs n'aiment pas (encore) la sécurité... mais vous pouvez changer la donne.

Vous connaissez la chanson : mentionnez la « sécurité » à un développeur lambda, et vous risquez de vous heurter au mieux à un soupir, au pire à de l'incompréhension. En général, toute cette histoire de sécurité est perçue comme le problème de quelqu'un d'autre.

La responsabilité première d'un développeur est de créer un logiciel fonctionnel, riche en fonctionnalités innovantes et livré dans des délais serrés. La sécurité est rarement une priorité au niveau du codage et peut même être perçue comme un frein fastidieux à une livraison rapide et à la créativité. L'AppSec a pour tâche de vérifier méticuleusement le code, d'effectuer des tests d'intrusion, puis d'annoncer les mauvaises nouvelles : la présence de vulnérabilités dans un code souvent déjà intégré et qui fonctionne très bien par ailleurs. C'est un processus coûteux dans un environnement souvent à court de ressources et de temps, une configuration vouée à créer un fossé entre deux équipes qui ont pourtant le même objectif, mais qui parlent des langages totalement différents.

Dans ce climat, l'accueil réservé à une formation obligatoire à la sécurité risque d'être assez glacial. Pourtant, le pouvoir d'insuffler une culture de la sécurité chez chaque développeur n'est pas une utopie. Avec le bon type de formation et de soutien, ils peuvent commencer à intégrer la sécurité dans leurs logiciels et assumer la responsabilité des résultats de sécurité qu'ils sont en mesure de contrôler. Si les développeurs eux-mêmes peuvent s'occuper des failles courantes, cela libère les spécialistes coûteux pour résoudre les problèmes vraiment complexes. Et si vous gérez une équipe de développement, vous pouvez jouer un rôle déterminant pour combler ce fossé et aider votre équipe à en percevoir les avantages.

Toutes les formations ne se valent pas.

À quand remonte la dernière fois où vous avez été vraiment enthousiaste à l'idée d'apprendre quelque chose de nouveau ? Dans ces moments-là, des mots comme « obligatoire », « conformité » ou « dix-sept heures de vidéo » ne vous viennent probablement pas à l'esprit.

Les développeurs ne sont pas différents. Ils sont intelligents, créatifs et aiment résoudre des problèmes. Il est très peu probable que regarder des vidéos interminables sur les vulnérabilités de sécurité les motive, rende le contenu mémorable ou soit adapté à leurs rôles et responsabilités quotidiens. Durant mon expérience en tant qu'instructeur SANS, il est apparu très tôt que la meilleure formation est pratique, obligeant les participants à analyser et à être mis au défi intellectuellement, en utilisant des exemples concrets qui stimulent leur réflexion et s'appuient sur leurs acquis. La gamification et la compétition amicale sont également des outils puissants pour faire adhérer tout le monde à de nouveaux concepts, tout en restant utiles et pratiques dans leur application.

Un autre facteur inquiétant est qu'une grande partie de la formation à la sécurité n'est pas suivie. Personne n'aime avoir l'impression d'être surveillé par Big Brother, mais quel est l'intérêt de consacrer du temps, de l'argent et des efforts à l'éducation si personne ne vérifie si elle est pertinente ?

La bonne solution peut rendre le codage sécurisé amusant, pertinent, engageant et mesurable. Mettez vos développeurs au défi, traitez-les bien et faites-en un événement spécial. La formation gamifiée active les centres de récompense du cerveau, et offrir une incitation à continuer d'apprendre, à repousser les limites des connaissances et, tout simplement, à construire un standard de logiciel plus élevé, est une situation gagnant-gagnant.

État des lieux de votre culture de sécurité : est-elle sous assistance respiratoire ?

Créer des logiciels sécurisés dans un environnement où la culture de la sécurité est faible revient à essayer de gagner un marathon avec un rocher enchaîné à la cheville : c'est pratiquement impossible et inutilement difficile.

La formation ludique, les tournois en duel et l'engagement à soutenir les développeurs dans leur montée en compétences en sécurité contribuent grandement à instaurer une culture de sécurité positive, permettant aux équipes AppSec et de développement de mieux comprendre le quotidien de chacun. Des relations plus solides se tissent, et le budget sécurité (souvent limité) n'est plus gaspillé à corriger indéfiniment les mêmes petits bugs récurrents.

Il existe un autre avantage majeur : la découverte de champions de la sécurité dont vous ignoriez l'existence. Une formation adaptée, impliquant tout le monde et permettant une évaluation approfondie, peut révéler des profils ayant non seulement des aptitudes pour la sécurité, mais aussi une réelle passion. Ces champions sont essentiels pour maintenir la dynamique, servir de lien entre les équipes, superviser leurs pairs et faire respecter les bonnes pratiques. Mettre en place un programme solide, soutenu par la direction et valorisant ces talents, est un atout pour l'organisation, tout en enrichissant le CV des collaborateurs et en boostant leur carrière.

En vous engageant en faveur d'une culture de sécurité positive, la responsabilité est partagée et un niveau d'excellence supérieur en matière de logiciels sécurisés peut être atteint. En fin de compte, chaque acteur du cycle de vie du développement logiciel doit adopter un mantra simple : un logiciel n'est pas de qualité s'il n'est pas sécurisé.

Faites passer le message.