Dans un monde dominé par le numérique, nous sommes de plus en plus exposés au risque de vol de données. Les grandes organisations étant les gardiennes de nos précieuses informations, nombre d'entre elles reconnaissent la nécessité de mettre en œuvre des normes de sécurité rigoureuses.

La plupart des initiatives visant à "passer à gauche", c'est-à-dire à introduire la sécurité beaucoup plus tôt dans le processus de développement, ne font tout simplement pas avancer l'aiguille assez loin. Cela implique que nous commençons toujours le processus de la mauvaise manière, en faisant finalement marche arrière pour atteindre le résultat d'un logiciel plus sûr. Nous devons commencer à gauche, en mettant en œuvre un changement culturel qui engage positivement les équipes de développement et les arme avec les connaissances qui leur manquent actuellement. Cependant, toutes les formations et tous les outils ne sont pas égaux.

Dans cet article, nous explorons les moyens par lesquels les principaux responsables, tels que les responsables de la sensibilisation à la sécurité et du développement, peuvent véritablement responsabiliser leur cohorte de développeurs, en les transformant en première ligne de défense contre les cyberattaques coûteuses.

Déplacement vers la gauche ou départ vers la gauche : Une distinction importante.

À l'ère des fréquentes violations de données affectant certaines des organisations les plus fiables au monde, les dirigeants d'entreprise se sont tournés vers l'industrie de la sécurité pour obtenir des conseils afin d'éviter le désastre financier, de réputation et de spectacle qu'est une attaque réussie.

Depuis un certain temps, les spécialistes de l'AppSec (dont je fais partie) conseillent de "passer à gauche". En accord avec les meilleures pratiques DevOps, ainsi qu'avec les meilleurs résultats en matière de sécurité des logiciels, beaucoup d'entre nous ont conseillé que la partie sécurité d'un logiciel soit intégrée plus tôt dans le cycle de vie du développement logiciel (SDLC). Elle ne devrait pas être l'étape finale et coûteuse, mais plutôt se rapprocher du début du processus, avec des équipes AppSec impliquées dès que les projets logiciels prennent vie.

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'âge des vulnérabilités utilisées pour les voler, ne fonctionne de toute façon pas). Cependant, si nous commencions à partir de la gauche, les résultats en matière de sécurité seraient bien plus positifs.

Passer à gauche, commencer à gauche... quelle est la différence ? La différence réside dans la manière dont vous engagez votre équipe de développement. En effet, ils sont la clé pour fournir des logiciels plus sûrs, à un coût bien inférieur à celui des chaînes d'outils de cycle ultérieur et de l'examen manuel du code. Dans un monde idéal, chaque développeur qui écrit un logiciel aurait les connaissances et les outils nécessaires pour coder de manière sécurisée dès le début. Ils repéreraient les failles potentielles et les atténueraient avant qu'elles ne soient validées (et donc beaucoup plus coûteuses à éliminer et à corriger). Il y aurait une réduction spectaculaire des bogues de sécurité que nous voyons depuis des décennies - ceux qui sont encore responsables de permettre aux attaquants d'entrer par la porte de derrière. Ces fenêtres d'opportunité sous forme d'injection SQL, de scripts intersites et d'authentification défectueuse se refermeraient.

Cependant, à l'heure actuelle, la sécurité n'est tout simplement pas suffisamment mise en avant au niveau professionnel, et la formation au codage sécurisé sur le lieu de travail varie considérablement. En conséquence, les développeurs disposent rarement de ce dont ils ont besoin pour permettre à une organisation de partir à gauche. Il est temps que les responsables travaillent ensemble et plaident en faveur d'une plus grande sensibilisation à la sécurité, leur connaissance directe et leur contact avec les développeurs étant essentiels pour mettre en place des programmes qui fonctionnent. Après tout, les responsables du développement étaient autrefois dans leur position, avec des outils et un espace de sécurité difficile à naviguer dans le meilleur des cas.

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

Vous savez ce qu'il en est : si vous parlez de "sécurité" à un développeur typique, vous risquez d'obtenir au mieux un haussement d'épaules, au pire de la perplexité. En général, la sécurité est considérée comme le problème de quelqu'un d'autre.

Un développeur a pour principale responsabilité de créer des logiciels fonctionnels, dotés de fonctionnalités innovantes et livrés dans des délais serrés. La sécurité est rarement une priorité au niveau du codage, et peut même être considérée comme un obstacle fastidieux à une livraison rapide et à la créativité. L'AppSec a pour tâche de vérifier méticuleusement le code, de procéder à des tests d'intrusion, puis de signaler les mauvaises nouvelles : la présence de vulnérabilités de sécurité dans un code qui a souvent déjà été validé et qui fonctionne très bien par ailleurs. Il s'agit d'un processus coûteux dans un environnement souvent à court de ressources et de temps, dont la mise en place est susceptible de provoquer un clivage entre deux équipes qui ont en fin de compte le même objectif, mais qui parlent des langues complètement différentes.

Dans ce contexte, l'accueil réservé à la formation obligatoire en matière de sécurité risque d'être plutôt froid. Mais le pouvoir de faire naître un état d'esprit de sécurité chez chaque développeur n'est pas une chimère. 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 qu'ils sont en mesure de contrôler en matière de sécurité. Si les développeurs eux-mêmes peuvent s'occuper des bogues courants, cela libère les spécialistes coûteux pour résoudre les problèmes vraiment complexes. Et si vous êtes en mesure de gérer une équipe de développement, vous pouvez contribuer à combler ce fossé et aider votre équipe à en voir les avantages.

Toutes les formations ne sont pas égales.

À quand remonte la dernière fois où vous avez été vraiment enthousiaste à l'idée d'apprendre quelque chose de nouveau ? Si c'est le cas, des mots comme "obligatoire", "conformité" ou "dix-sept heures de vidéo" ne vous sont probablement pas venus à l'esprit.

Les développeurs ne sont pas différents. Ils sont intelligents, créatifs et aiment résoudre des problèmes. Il est peu probable que le fait de regarder d'interminables vidéos sur les vulnérabilités en matière de sécurité les intéresse, que le contenu reste mémorable ou qu'il soit spécifique à leur rôle et à leurs responsabilités au quotidien. En tant qu'instructeur SANS, il m'est apparu très tôt que la meilleure formation est pratique, obligeant les participants à analyser et à être défiés intellectuellement, en utilisant des exemples du monde réel qui mettent leur cerveau à l'épreuve et s'appuient sur leurs connaissances antérieures. 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 l'application.

Un autre facteur effrayant est qu'une grande partie de la formation en matière de sécurité n'est pas surveillée. Personne n'aime avoir l'impression que Big Brother l'observe, mais à quoi bon consacrer du temps, de l'argent et des efforts à la formation si personne n'en vérifie la pertinence ?

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 stimule les centres de récompense du cerveau et offre une incitation à continuer à apprendre, à repousser les limites de la connaissance et, tout simplement, à construire un logiciel de meilleure qualité, c'est une situation gagnant-gagnant.

Bilan de santé de la culture de la sécurité : La vôtre est-elle sous respirateur artificiel?

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

La formation par le jeu, les confrontations directes sur tournaments et l'engagement à aider les développeurs dans leur développement en matière de sécurité contribuent énormément à créer une culture de sécurité positive, les équipes d'AppSec et de développement ayant une meilleure connaissance du travail quotidien de chacun. De meilleures relations se développent et prospèrent, et le budget de sécurité (souvent limité) n'est pas épuisé par la correction des mêmes petits bogues gênants, comme dans un "jour de la marmotte".

Il existe également un autre sous-produit puissant : la découverte des champions de la sécurité dont vous ne soupçonniez pas l'existence. Une formation appropriée qui implique tout le monde, tout en permettant un examen approfondi du site assessment, peut permettre de découvrir ceux qui ont non seulement des aptitudes en matière de sécurité, mais qui en sont également passionnés. Ces champions sont essentiels pour maintenir l'élan et servir de point de contact entre les équipes, superviser les pairs et faire respecter les politiques de meilleures pratiques. La mise en œuvre d'un solide programme de champions, qui inclut la reconnaissance et le soutien de la direction, est un atout pour l'organisation, mais aussi pour le CV de la personne concernée et pour sa future carrière.

Lorsque vous vous engagez dans une culture de sécurité positive, la responsabilité est partagée et un niveau plus élevé d'excellence en matière de logiciels sécurisés peut être atteint. En fin de compte, chaque personne intervenant dans le cycle de développement des logiciels doit adhérer à un mantra simple : s'il ne s'agit pas d'un logiciel sécurisé, il ne s'agit pas d'un bon logiciel.

Faites passer le message.

Les meilleures pratiques en matière de cybersécurité sont un sujet brûlant depuis plus d'une décennie, fréquemment débattu au niveau gouvernemental dans la plupart des régions du monde. Les cyberattaques sont essentiellement une réalité quotidienne, et toute entité stockant des données privées précieuses en ligne est une cible potentielle. Rien qu'en Allemagne, le ministère fédéral de l'éducation et de la recherche estime que 96 % des petites et moyennes entreprises ont déjà subi un incident de sécurité informatique. Le même rapport souligne le besoin urgent de recherche, de législation et de sensibilisation en matière de cybersécurité, en insistant sur l'importance d'une formation plus solide en matière de sécurité dans les domaines de l'informatique et des technologies de l'information.

Avec l'arrivée du GDPR, ainsi qu'une stratégie révisée suite à une attaque en plusieurs étapes qui a exposé les données sensibles de nombreuses personnalités publiques - ainsi que des serveurs du gouvernement fédéral allemand - il est clair que la sensibilisation et l'action en matière de cybersécurité sont au premier plan des préoccupations des dirigeants de la région DACH. Le piratage de la fin de l'année 2018 a été réalisé par un étudiant de 20 ans relativement peu qualifié, dont le principal point d'accès à des informations très sensibles a été obtenu en devinant simplement des mots de passe. Bien qu'il s'agisse d'un exploit d'authentification extrêmement préoccupant, il a mis en évidence la nécessité d'une bien meilleure sensibilisation à la sécurité au niveau des gouvernements, des entreprises et de la société. Un rapport de 2019 a souligné que l 'Allemagne était à la traîne en termes d'initiatives de défense de la cybersécurité, s'appuyant sur la législation comme principale tactique. Cependant, avec l'arrivée de DevSecOps en tant que méthodologie de développement idéale, de nombreuses entreprises ont reconnu la nécessité d'une formation pratique, de la création de logiciels sécurisés dès la conception et de programmes de sensibilisation à la sécurité à l'échelle de l'entreprise.

Le cœur de la sécurité des logiciels dans le DACH

Des organisations comme OWASP et MITRE publient des classements vérifiés des vulnérabilités les plus fréquentes. Dans tous les langages, l'injection SQL occupe la première place et, bien qu'elle date de plusieurs décennies, il s'agit d'une faille courante, souvent exploitée avec des conséquences désastreuses.

Le logiciel bancaire suisse BPC, SmartVista, a été alerté d'une vulnérabilité SQLi par SwissCERT, mais il est resté sans correctif pendant des mois malgré son potentiel à exposer les données sensibles des clients, y compris les numéros de cartes de crédit. L'injection SQL peut conduire et conduit effectivement à des violations dangereuses, à l'instar de la violation en 2017 de plusieurs ministères et universités aux États-Unis et au Royaume-Uni. Nombre de ces incidents sont dus à des processus de validation d'entrée laxistes, qui permettent à un pirate d'insérer un code malveillant à partir de la partie frontale d'une application. Une autre source de vulnérabilité courante est l'utilisation d'un code fournisseur non sécurisé qui n'est pas vérifié pour les bogues de sécurité, et des failles sont ainsi introduites dans un environnement de production précédemment analysé et nettoyé. Aucun de ces points d'accès n'est spécifique à la région DACH, il s'agit plutôt d'exemples globaux de mauvaises pratiques de sécurité qui ne peuvent perdurer alors que le monde produit de plus en plus de code.

Il est impératif de corriger les problèmes dès qu'ils sont découverts, et la décision de SmartVista de traîner les pieds aurait pu être un désastre. Bien que DACH ait connu sa part de violations, des lignes directrices et un soutien plus ciblés en matière de sensibilisation et de formation à la sécurité pourraient empêcher les problèmes potentiels au niveau organisationnel de devenir incontrôlables, et cela nécessitera une législation beaucoup plus spécifique en matière d'évaluation de la formation pour les développeurs.

Toutes les formations au codage sécurisé ne sont pas équivalentes.

De nombreuses directives sur la cybersécurité dans le monde sont de plus en plus complètes, mais elles restent peu précises lorsqu'il s'agit de définir une formation efficace en matière de sécurité. La directive NIS de l'UE prévoit bien la nécessité de "sensibiliser, former et éduquer" au niveau national, mais se précipiter sur une solution de formation peut ne pas avoir le résultat escompté, à savoir une réduction tangible des risques, s'il manque des éléments clés qui stimulent les développeurs de compétences et les changements organisationnels.

Les solutions de formation varient, et la formation doit être spécifique au travail quotidien du développeur (y compris la possibilité d'apprendre dans son langage et son cadre préférés), tout en restant attrayante et mesurable au fil du temps.

Les solutions de formation statiques, telles que les formations vidéo sur ordinateur, sont souvent trop génériques et rarement revues ou évaluées quant à leur capacité à sensibiliser les développeurs et à leur permettre d'empêcher les vulnérabilités de pénétrer dans le code en cours d'écriture. La formation dynamique, en revanche, est essentielle pour renforcer les compétences des développeurs à l'aide d'exemples contextuels, en plus de fournir des mesures qui influencent les processus d'atténuation de l'activité. Elle est fréquemment mise à jour, favorise un niveau élevé de rétention des connaissances et fait partie de la construction de développeurs sensibilisés à la sécurité qui contribuent à une culture positive de la sécurité sur leur lieu de travail.

Secure Code Warrior points de données des projets pilotes DACH :

Secure Code WarriorEma Rimeike, directrice des ventes (MSc en cybersécurité), travaille en étroite collaboration avec des organisations de la région DACH, menant des programmes pilotes pour les développeurs afin d'évaluer leurs compétences internes en matière de codage sécurisé, leur engagement envers les meilleures pratiques de sécurité, ainsi que la culture générale de sécurité de l'entreprise. Grâce à une formation dynamique et ludique au codage sécurisé, ses principales conclusions révèlent un avenir prometteur lorsque les développeurs reçoivent les connaissances et les outils qui favorisent une réduction réussie des vulnérabilités dès le début du cycle de développement durable.

Au cours de ses programmes pilotes, elle a recueilli des statistiques basées sur une moyenne de 90 minutes passées par chaque utilisateur sur la plateforme Secure Code Warrior (SCW), au cours desquelles ils ont joué à 15 défis de codage sécurisés(leçons de taille réduite, ludiques et autodidactes) :

Les utilisateurs ont passé en moyenne 5,5 minutes à relever un défi, contre 3 minutes en moyenne pour les autres projets pilotes mondiaux de SCW.

• Précision et confiance : Les pilotes DACH ont enregistré un pourcentage moyen de 88 à 92 % de confiance dans leurs réponses aux défis, alors que la précision de ces réponses se situait entre 53 et 66 %.
• Plus de 75 % des participants à l'enquête préfèrent les méthodes de formation dynamiques, par opposition aux approches statiques telles que la formation assistée par ordinateur (FAO).
• Parmi les vulnérabilités les plus fréquentes, nous avons constaté des failles d'injection, une mauvaise configuration de la sécurité, des scripts intersites (XSS), une mauvaise utilisation de la plate-forme, un contrôle d'accès, une authentification, une corruption de la mémoire, une falsification des requêtes intersites, une protection insuffisante de la couche de transport et des redirections et des renvois non validés.

Ce n'est un secret pour personne que, de manière générale, une forte éthique de travail et l'accent mis sur la précision sont appréciés par de nombreuses personnes dans la région DACH, et les développeurs qui tentent le programme pilote ne font pas exception à la règle. Ces données témoignent de leur méconnaissance de ce type d'entraînement, mais aussi de leur désir de continuer à jouer, d'améliorer leur score et d'éviter d'utiliser la fonction "indice" disponible. Leur désir d'apprendre et de s'améliorer est évident, mais il montre aussi qu'il reste du travail à faire pour mettre en œuvre une formation et une sensibilisation efficaces au sein de l'organisation elle-même.

Une formation de qualité qui réduit les risques et déjoue les vulnérabilités n'est pas un exercice ponctuel, et c'est plus qu'une question de conformité. Les responsables et le personnel AppSec doivent s'efforcer de mettre en place un programme de sensibilisation à la sécurité avec une stratégie et un soutien qui reflètent les principaux objectifs de sécurité et cherchent à les maintenir à long terme. C'est en fait l'épine dorsale d'un processus DevSecOps réussi avec des développeurs sensibilisés à la sécurité.

Que révèle un programme pilote pour une organisation ?

Secure Code WarriorLes programmes pilotes de la Commission européenne sont un outil extrêmement précieux qui donne aux entreprises un aperçu de leur niveau de sécurité actuel (généralement entre 65 et 75 %), ainsi que des domaines dans lesquels des améliorations immédiates sont nécessaires. Ils révèlent

• La clarté sur les vulnérabilités qui doivent être traitées en priorité, ainsi que la question de savoir si cette orientation doit s'appliquer à une équipe, à une unité opérationnelle ou à un langage de programmation en particulier.
• une connaissance précise et plus large des facteurs de risque en matière de cybersécurité dans le cadre du cycle de développement des logiciels, qui englobe le facteur humain du développement des logiciels.
• En tirant parti de la plateforme SCW, les organisations peuvent prévoir les résultats potentiels des tests d'intrusion et avoir la possibilité d'atténuer ces risques en amont, en préparant les équipes avant même qu'elles ne soient affectées à un projet spécifique.

Dans les organisations qui ont commencé à déployer des programmes de sécurité complets et efficaces, une heure à une heure et demie par semaine de développement professionnel est approuvée au niveau de la direction, afin d'aider les développeurs à améliorer leurs connaissances en matière de codage sécurisé. Cependant, nous remarquons que les organisations s'éloignent du "temps passé sur la plateforme" pour se concentrer sur "les équipes de développement de logiciels qui présentent le risque le plus élevé et le risque le plus faible pour l'entreprise". Cette évolution est étroitement liée à une certification formalisée, à la découverte de champions de la sécurité et à des programmes de mentorat pour obtenir les meilleurs résultats. L'allocation de temps, ainsi que le site assessment constructif et positif, sont absolument essentiels pour créer des développeurs sensibilisés à la sécurité qui non seulement aiment la sécurité, mais réduisent de manière mesurable les risques pour l'entreprise.

Comment les organisations utilisent-elles déjà Secure Code Warrior?

Plusieurs entreprises utilisent déjà le site Secure Code Warrior pour sensibiliser le public, renforcer les compétences des développeurs et développer une culture de la sécurité positive.

Par exemple, dans un cas d'utilisation, une équipe en formation sur la plateforme a utilisé le SCW pour révéler ses forces et faiblesses en matière de sécurité :  

Action des développeurs : Les développeurs ont pu voir leurs propres résultats, indiquant les domaines sur lesquels ils devraient se concentrer et leur permettant de s'autogérer, et de suivre la formation pour atténuer les vulnérabilités spécifiques ou les lacunes en matière de connaissances qui les aideront dans les futurs développements de logiciels.

Action de la direction : Ils ont analysé les forces et les faiblesses globales de l'équipe et ont pu prescrire une approche ludique qui répond aux domaines spécifiques de préoccupation. Cela a créé un parcours éducatif à double sens qui permet d'acquérir rapidement des connaissances pertinentes.

Résultat : Une fois le pentesting effectué au niveau de l'équipe, toutes les vulnérabilités sont visibles, et la comparaison des résultats précédents a permis de valider facilement si la formation avait été efficace pour réduire les bogues de sécurité courants.

Cela nous ramène aux étapes initiales du développement de logiciels, où la formation préalable des équipes aux objectifs d'amélioration continue et l'introduction des meilleures pratiques de sécurité dès le départ peuvent être efficaces, faciles à mettre en œuvre et faire gagner du temps à l'ensemble du développement.

Équipes de projet DevSecOps

Dans un environnement DevSecOps idéal, plusieurs unités opérationnelles sont représentées au sein d'une équipe de projet afin de décider et d'obtenir des résultats essentiels, dont les meilleures pratiques en matière de sécurité.

En termes de recherche et de planification pré-projet, la plateforme SCW peut évaluer les compétences en matière de sécurité de l'équipe de développement proposée avant qu'elle ne commence à travailler, en prédisant les résultats éventuels du pentesting et les retards liés à la sécurité dans le SDLC avec plus de temps qu'il n'en faut pour s'y préparer de manière adéquate. Une formation spécifique au code et à la structure du projet peut être créée pour l'équipe, y compris un processus de certification assessment qui vérifie les compétences générales en matière de sensibilisation à la sécurité, exigeant une note de passage prédéfinie avant que l'équipe ne soit libre de travailler sur les produits livrables du projet.

Cette approche présente une immense valeur commerciale en réduisant le coût de la correction des vulnérabilités, en atténuant les risques de sécurité, en gagnant du temps dans les tests de pénétration, en réduisant le coût des programmes de primes coûteux et en améliorant les compétences de la cohorte de développement d'une manière centralisée, durable, évolutive et unifiée.

Conclusion :

Les entreprises subissent une pression accrue pour donner la priorité à la sécurité, assurer la protection de nos données et se conformer à des réglementations de plus en plus strictes à l'échelle mondiale, mais surtout pour les organisations qui exercent des activités commerciales dans l'UE dans le cadre des directives strictes du GDPR.

Pour les entreprises de la région DACH, il est clair qu'elles créent des parcours de sécurité viables en reliant les efforts et les résultats de la formation à des activités réelles liées à la prévention des risques, y compris la réduction des vulnérabilités courantes dans le code qu'elles produisent.

Pour construire un dossier commercial réellement quantifiable en vue d'augmenter les budgets de sécurité, la sensibilisation et la conformité globale, la formation doit être attrayante pour les développeurs, cohérente, adaptable et mesurable. Le suivi des niveaux actuels de capacité pour adapter la bonne formation, la découverte des champions de la sécurité et la mesure des performances de l'équipe au fil du temps sont autant d'initiatives vitales, et de nombreuses entreprises avant-gardistes à travers le DACH en réalisent les avantages à la suite d'un projet pilote SCW complet.

De nombreuses entreprises se débattent avec des mesures de performance en matière de sécurité qui sont trop génériques. Avec une utilisation cohérente et à long terme de la plateforme SCW, les entreprises pourraient utiliser des évaluations de précision, courses, et des mesures de gestion pour découvrir :

• Réduction des vulnérabilités au fil du temps
• Réduction du coût de la correction des vulnérabilités au fil du temps
• Développement des compétences individuelles et collectives au fil du temps
• Réduction des coûts et des délais au stade du pentesting

Quelles sont les mesures actuellement suivies par votre organisation, à quelle fréquence sont-elles réévaluées et ont-elles montré une nette amélioration au fil du temps ? Dans quelle mesure vos initiatives de formation sont-elles intégrées dans le flux de travail existant des développeurs ?

L'approche dynamique, ludique et globale du SCW est considérée comme un élément essentiel du cycle de vie du développement de logiciels sécurisés. Les entreprises dotent leurs développeurs des outils et de la formation appropriés, et intègrent le SCW dans leur flux de travail SSDLC.

Cet article a été publié à l'origine dans Information Security Buzzet a été repris par plusieurs autres médias. Il a été mis à jour pour syndication ici.

Vers la fin de l'année dernière, l'incroyable communauté de MITRE a publié sa liste des 25 erreurs logicielles les plus dangereuses du CWE qui ont affecté le monde en 2019. Cette liste n'est pas basée sur une opinion, elle est le résultat d'une analyse à multiples facettes utilisant le travail d'organisations telles que le NIST, ainsi que les données publiées sur les vulnérabilités et expositions communes (CVE). Afin de déterminer les "principales" failles, une note est attribuée en fonction de leur gravité, de leur exploitabilité et de leur prévalence dans les logiciels actuels. Ce n'est pas le genre de liste qui vous vaudra des éloges, c'est certain.

Cependant, contrairement à la majorité des bilans annuels, de nombreux participants à cette liste sont déjà apparus auparavant... encore et encore. S'il s'agissait du classement Billboard Hot 100, ce serait comme si Britney Spears"Baby One More Time" et les Backstreet Boys"I Want It That Way" apparaissaient chaque année depuis leur sortie initiale. Pourquoi ai-je choisi ces chansons ? Eh bien, elles ont environ vingt ans (vous vous sentez déjà vieux ?), tout comme certaines de ces dangereuses erreurs logicielles qui continuent de nous affliger en 2020 bien qu'elles aient été découvertes il y a plusieurs dizaines d'années.

Pourquoi les vieux bugs sont-ils encore si dangereux ? Ne savons-nous pas comment les corriger ?

Le numéro six de la liste actuelle de MITRE est le CWE-89, mieux connu sous le nom d'injection SQL (SQLi). La vulnérabilité SQLi a été découverte pour la première fois en 1998, à l'époque où beaucoup d'entre nous posaient encore leurs questions brûlantes à Asking Jeeves plutôt qu'à Google. Un correctif a été rendu public peu de temps après, et pourtant, cela reste l'une des techniques de piratage les plus utilisées en 2019. L'étude d'Akamai État des lieux de l'Internet d'Akamai a révélé que SQLi était le coupable de deux tiers de toutes les attaques d'applications web.

En termes de complexité, l'injection SQL est loin d'être un exploit de génie. Il s'agit d'une solution simple pour un développeur web , et nous savons sans hésitation comment empêcher cette vulnérabilité d'exposer des données précieuses à un attaquant... le problème est que pour de nombreux développeurs, même aujourd'hui, la sécurité n'est pas une priorité. C'était peut-être plus facile il y a vingt ans, mais vu le volume de logiciels créés aujourd'hui et à l'avenir, cela ne peut plus rester la norme.

Les développeurs travaillent dans un système défaillant (la plupart du temps).

Il est trop facile de s'asseoir et de blâmer les développeurs pour avoir produit un "mauvais" code. En réalité, leurs priorités sont très différentes de celles de l'équipe de sécurité. L'équipe de développement moyenne a pour mission de créer des logiciels beaux et fonctionnels aussi rapidement que possible. Le besoin insatiable de la société en logiciels fait que les équipes de développement sont déjà surchargées et que la sécurité n'est pas une considération primordiale ; après tout, n'est-ce pas la raison d'être des spécialistes de l'AppSec ? Les ingénieurs logiciels sont habitués à une relation quelque peu froide avec la sécurité - ils n'entendent parler d'eux qu'en cas de problèmes, et ces problèmes peuvent retarder la production de leur travail acharné.

De l'autre côté de la barrière, les spécialistes de l'AppSec en ont assez de réparer des erreurs vieilles de plusieurs dizaines d'années qui reviennent sans cesse dans chaque analyse et examen manuel du code. Ces spécialistes sont chers et rares, et leur temps est bien mieux employé à corriger des failles de sécurité complexes qu'à éliminer des bogues bien connus, encore et encore.

Il existe une culture tacite qui consiste à pointer du doigt ces équipes, mais elles ont (ou devraient avoir) le même objectif : des logiciels sûrs. Les développeurs évoluent dans un environnement qui leur donne rarement les meilleures chances de réussite en termes de codage sécurisé ; les meilleures pratiques en matière de sécurité sont rarement enseignées dans le cadre de leur formation supérieure, et la formation sur le tas est souvent beaucoup trop rare, voire totalement inefficace. L'accent n'est pas mis sur la sensibilisation à la sécurité et sur une formation approfondie et pertinente, ce qui se traduit par le coût astronomique de la correction de vieux bogues dans un code engagé, ainsi que par la menace imminente d'une atteinte à la réputation de l'entreprise.

Le facteur humain, alias "Pourquoi tous ces outils ne rendent-ils pas nos données plus sûres ?".

Un autre problème qui apparaît fréquemment est qu'en lieu et place de la formation, un vaste arsenal d'outils de sécurité est mis à contribution pour détecter les problèmes avant que le logiciel ne soit diffusé dans la nature. Les outils d'analyse et de protection des applications(SAST/DAST/RASP/IAST) peuvent certainement contribuer à sécuriser la production de logiciels, mais ils posent leurs propres problèmes. Le fait de s'en remettre entièrement à eux ne garantit pas la sécurité, car.. :

• Aucun outil ne peut détecter toutes les vulnérabilités, dans tous les cadres et dans tous les cas d'utilisation.
• Ils peuvent être lents, surtout lorsqu'ils fonctionnent en tandem pour fournir une analyse statique et dynamique du code.
• Les faux positifs restent un problème ; ils interrompent souvent la production et nécessitent un examen manuel inutile du code pour donner un sens aux alertes.
• Ils créent un faux sentiment de sécurité, en privant le codage de sécurité de toute priorité dans l'espoir que ces outils détecteront tous les problèmes.

Les outils vont certainement déceler des failles de sécurité qui peuvent être corrigées, mais vont-ils tout trouver ? Il est impossible de garantir un taux de réussite de 100 %, et il suffit à un pirate de laisser une porte ouverte pour s'introduire dans votre système et vous gâcher la vie.

Heureusement, de nombreuses organisations prennent conscience du facteur humain en jeu dans les vulnérabilités des logiciels. La plupart des développeurs ne sont pas formés de manière adéquate à la codification sécurisée, et leur sensibilisation générale à la sécurité est faible. Pourtant, ils se trouvent au tout début du cycle de développement des logiciels et sont les mieux placés pour empêcher les vulnérabilités de se frayer un chemin jusqu'au code validé. S'ils codaient de manière sécurisée dès le départ, ils constitueraient les premières lignes de défense contre les cyberattaques dévastatrices qui nous coûtent des milliards chaque année.

Les développeurs doivent avoir la possibilité de s'épanouir, grâce à une formation qui parle leur langue, qui soit adaptée à leur travail et qui les incite à s'intéresser activement à la sécurité. Un code sans bogue devrait être un motif de fierté, tout comme la création d'un produit fonctionnellement génial vous vaudra le respect de vos pairs.

Un programme de sécurité moderne devrait être une priorité pour les entreprises.

Les équipes de développement ne peuvent pas se prendre en main et mettre en place une sensibilisation positive à la sécurité dans l'ensemble de l'entreprise. Elles auront besoin des outils, des connaissances et du soutien nécessaires pour intégrer la sécurité dans le processus de développement des logiciels dès le début.

Les anciennes méthodes de formation ne fonctionnent manifestement pas si la liste de MITRE présente toujours autant de bogues de sécurité, alors essayez quelque chose de nouveau. Recherchez des solutions de formation qui sont :

• Les développeurs aiment apprendre par la pratique et non pas en regardant des vidéos où l'on parle à tort et à travers.
• Pertinent ; ne les obligez pas à suivre une formation en C# s'ils utilisent Java tous les jours.
• Engageant ; l'apprentissage par petits bouts est facile à digérer et permet aux développeurs de continuer à développer leurs connaissances antérieures.
• Mesurables ; ne vous contentez pas de cocher une case et de passer à autre chose. Veillez à ce que la formation soit efficace et créez des voies d'amélioration.
• Amusant ; regardez comment vous pouvez sensibiliser à la sécurité tout en soutenant une culture de sécurité positive, et comment cela peut créer un environnement d'équipe cohésif.

La sécurité devrait être une priorité absolue pour tous les membres de l'organisation, le RSSI étant visible et transparent quant aux efforts déployés à tous les niveaux pour assurer la sécurité de nos données. Qui a envie d'entendre la même chanson à répétition ? Il est temps de prendre au sérieux l'élimination des vieux bogues pour de bon.

Lorsque l'on parle de "croissance" dans le contexte d'une entreprise, il s'agit presque toujours de mesures, de revenus, de financement, de nombre d'employés... toutes ces choses auxquelles je n'avais pas à penser il y a une dizaine d'années.

J'aurais pu commencer cet article avec tous ces faits et chiffres ; ils sont indéniablement impressionnants et la trajectoire de notre entreprise en cours est solide. Cependant, pour moi, ces chiffres ne reflètent pas ce dont je suis le plus fier en 2019. La réalité est que nous avons construit une équipe vraiment spectaculaire de personnes qui se soucient bien au-delà des métriques financières simples. Nous avons connu une "poussée de croissance", qui a façonné l'énorme cœur de cette entreprise aujourd'hui et à l'avenir.

Permettez-moi de vous le démontrer, cher lecteur :

‍

Nous avons mis en place le programme Warriors Give Back, une initiative caritative mondiale qui a donné lieu à plus de 10 événements sur 12 mois à Sydney, Boston, Londres et Bruges :

• 50 Warriors ont construit des bicyclettes avec l'organisation Bikes for Tykes, pour les donner à des enfants défavorisés de Sydney.
• 9 Warriors à Boston se sont portés volontaires à la Cradles to Crayons Giving Factory, triant et empaquetant les dons pour les enfants locaux dans le besoin.
• Les membres de l'équipe ont soutenu les sans-abri, tout en découvrant une infime partie de ce que c'est que de faire les courses pour une semaine de repas, avec seulement dix dollars en main et sans chauffage ni réfrigération.
• À Bruges, les Warriors ont aidé 100 enfants à participer aux activités de la CyberSkool, notamment la construction de robots, le piratage et le crochetage de serrures.
• Les Warriors ont acheté des articles pour les paniers de Noël, ainsi que des jouets pour les enfants dans le besoin avec Wesley City Connect.
• Nos Warriors basés à Londres ont sponsorisé une école primaire locale en lui fournissant du matériel et ont rejoint l'équipe environnementale de l'école pour nettoyer ses terrains de jeu.
• Nous avons établi un partenariat avec TechLadies + the WING, qui propose gratuitement une aide à la rédaction de CV et un accompagnement professionnel personnalisé.
• Dans le cadre de notre célébration de fin d'année, nous avons acheté des cadeaux de Noël pour des familles locales dans le besoin, en partenariat avec le programme "Adoptez une famille" de l'ABCD. Ce service met en relation des familles dans le besoin avec des particuliers, des organisations à but non lucratif et des entreprises qui souhaitent aider une famille pendant les fêtes de fin d'année ou tout au long de l'année.

Et avec l'une des pires saisons de feux de brousse jamais enregistrées en Australie, nous nous sommes unis pour faire un don au Rural Fire Service et à WIRES juste avant que l'année ne s'achève dans la tristesse. Il s'agit d'une crise permanente où rien ne semble suffisant, mais j'ai été touchée par l'empathie dont a fait preuve notre équipe mondiale.

Ces événements "Warriors Give Back" nous rappellent régulièrement qu'il n'y a pas que les chiffres dans la vie, et que nous sommes tous mieux fondés en faisant l'effort de nous mettre à la place d'autres personnes moins fortunées. L'humanité et l'humilité sont essentielles au maintien d'une culture positive, et notre équipe s'en fait le champion à chaque occasion.

Vous êtes toujours là pour les chiffres ?

En ce qui concerne notre produit, nous avons créé 1727 nouveaux défis de codage sécurisé en 2019, à travers dix nouveaux cadres linguistiques. Il s'agit d'une réalisation colossale pour notre équipe d'ingénieurs, qui a produit en moyenne 144 nouveaux défis par mois - plus que toute autre année précédente à ce jour. En ce qui concerne nos utilisateurs, quelques chiffres intéressants ont également fait surface :

• Le langage/framework le plus populaire était Java : Spring, avec 455 973 défis de codage sécurisés relevés.
• Pseudocode a été une superstar inattendue, avec 295 763 défis joués.
• La catégorie de vulnérabilité la plus populaire est celle des failles d'injection, ce qui n'est pas une surprise. Elle est numéro un dans le Top 10 de l'OWASP, et numéro un pour nous.

Notre peuple en chiffres.

Lorsque j'ai créé cette entreprise, j'ai clairement indiqué que la diversité allait jouer un rôle déterminant dans notre réussite future. Je ne veux pas être coincé dans une chambre d'écho composée de personnes qui me ressemblent ; les différences d'opinion, de culture, de sexe, de régime alimentaire et de race font partie de la magie d'une startup internationale. À l'heure actuelle, notre équipe est composée de

• 17 nationalités différentes
• 53% d'hommes, 47% de femmes
• Au moins 9 régimes alimentaires différents (il y a eu des moments où la seule chose que nous pouvions manger en toute sécurité était du pop-corn).
• De multiples confessions dans tous les pays du monde.

Je suis immensément fier de notre équipe dynamique, et cela se voit dans tout ce que nous faisons.

Oh, et oui, notre chiffre d'affaires a augmenté de plus de 100 %, nous avons bouclé notre cycle de financement de série B (ce qui représente le plus gros investissement américain jamais réalisé dans une entreprise australienne de cybersécurité), nous sommes rapidement passés à une équipe de 120 personnes et nous avons ouvert de nouveaux bureaux à Portland et à Singapour.

C'est notre cinquième anniversaire, et bien que l'entreprise ait le même âge que ma fille, les similitudes entre leurs parcours ont pris fin. Heureusement, il me reste encore quelques années pour la voir devenir une adulte heureuse et en bonne santé. Avec les enfants, ces années passent en un clin d'œil, mais Secure Code Warrior n'est plus le bambin effronté. Plus vite que je ne l'aurais imaginé il y a cinq ans, nous avons dû passer à l'âge adulte et voler de nos propres ailes. Nous sommes prêts à emprunter le chemin de l'hypercroissance, mais je dois encore me faire à l'idée que l'adulte responsable, c'est moi.

Cet article a été publié à l'origine sur DevOps.com. Il a été mis à jour et modifié.

Tout comme "blockchain", "big data" et "digital disruption", le terme "DevOps" est un autre mot à la mode actuellement lancé dans les départements informatiques des grandes organisations.

Nombreux sont ceux qui ont identifié (à juste titre) la nécessité d'accélérer les cycles de développement des logiciels ; un processus plus précis, étroitement aligné sur les objectifs de l'entreprise, permettant un flux de travail plus clair et une collaboration entre les équipes de développement et les équipes opérationnelles. DevOps est essentiellement un développement "agile", qui a grandi et qui est prêt à répondre aux besoins d'innovation constante et de déploiement rapide de l'entreprise moderne. Pour les professionnels de la sécurité, il s'agit d'une initiative fantastique : nous pouvons injecter la sécurité dans le processus bien plus tôt, ce qui réduit le coût de la correction des bogues et permet d'éviter des catastrophes potentielles en cours de route.

Le problème, c'est que peu d'entreprises réussissent vraiment à mettre en œuvre DevOps. Sans le soutien, l'encouragement et la compréhension nécessaires au sein de l'entreprise, le projet peut rapidement devenir un éléphant blanc... vous savez, l'un de ces projets dont on ne parle pas de la guerre.

Quel est donc le problème ? C'est une discussion intéressante, et il y a quelques façons d'aborder DevOps qui, à mon avis, faciliteront grandement la navigation. Un programme efficace va au-delà de quelques nouveaux outils, titres et réunions d'équipe. Ce ne sera pas toujours facile, mais prendre le temps de réparer une stratégie défaillante (ou de la mettre en œuvre de la bonne manière dès le départ) sera beaucoup moins douloureux à long terme. Et au bout du compte, vous obtiendrez des logiciels de meilleure qualité et plus sûrs.

Voyons cela en détail :

Lâchez les ficelles du tablier "Agile".

Il existe une idée fausse selon laquelle une organisation doit choisir entre Agile et DevOps, et s'engager dans une voie ou dans l'autre pour ne jamais revenir en arrière.

En réalité, le processus de développement fonctionne mieux lorsque les deux sont pris en compte et mis en œuvre en même temps. DevOps n' est pas une réinvention du développement Agile, mais plutôt une extension de celui-ci. Les roues ont tendance à tomber lorsqu'on s'attend à ce que le processus soit exactement comme Agile, ou complètement différent d'Agile.

La méthode Agile soutient le principe des équipes interfonctionnelles, en réunissant les concepteurs, les testeurs et les développeurs dès le début et en s'engageant à ouvrir les lignes de communication tout au long d'un projet. Son objectif est de mettre fin aux livraisons cloisonnées et de réduire le double traitement, deux éléments qui sont également des avantages du processus DevOps. Cependant, DevOps va plus loin, en introduisant les systèmes, la sécurité et les opérations dans le mélange pour offrir un ensemble de compétences robuste et de bout en bout qui a pour but ultime la livraison d'un logiciel complet et fonctionnel au client.

Lors des inévitables points de douleur liés au passage à un processus plus centré sur DevOps, le risque de développement en silo peut réapparaître. Il arrive souvent que l'équipe Agile d'origine travaille ensemble, alors que les ajouts de sécurité et d'opérations sont encore en train de se frayer un chemin dans la machine ; personne ne sait vraiment comment les inclure, ce qu'ils doivent faire et leurs objectifs globaux.

DevOps ne fonctionne pas sans des objectifs clairement définis, une intégration interfonctionnelle et une communication directe avec toutes les parties. Il y aura une période d'adaptation qui nécessitera une gestion prudente du changement, certes, mais faire en sorte que tout le monde soit d'accord avec les améliorations que la fonctionnalité DevOps apportera, c'est la moitié de la bataille.

De plus en plus (Dieu merci), DevOps met l'accent sur les meilleures pratiques de sécurité dans le cadre du processus également, démystifiant cette étape et comblant le fossé entre l'équipe de sécurité et, bien, tout le monde. Comme je l'ai déjà dit, nous avons encore un long chemin à parcourir pour donner aux développeurs les moyens de coder de manière sécurisée dès le départ, mais la mise en œuvre réussie des méthodologies DevOps est une excellente base sur laquelle les compétences en matière de sécurité peuvent être développées au sein de l'équipe de développement.

L'automatisation n'est pas tout (et elle n'est pas la plus sûre).

Une autre caractéristique de la méthodologie DevOps est, dans une certaine mesure, l'automatisation du processus de développement de logiciels. Les principes d'intégration et de livraison continues (CI/CD) sont les pierres angulaires de ce concept et, comme vous pouvez le deviner, ils sont très dépendants des outils.

Les outils sont géniaux, ils le sont vraiment. Ils peuvent apporter une rapidité sans précédent au processus de livraison de logiciels, en gérant le dépôt de code, les tests, la maintenance et les éléments de stockage avec une facilité relativement transparente.

Cependant, si les robots peuvent un jour prendre tous nos emplois et nous emprisonner, ils n'en sont pas encore là. Une forte dépendance à l'égard des outils et de l'automatisation laisse le champ libre aux erreurs. Les analyses et les tests peuvent ne pas tout détecter, le code peut ne pas être vérifié, ce qui pose d'énormes problèmes de qualité (sans parler de la sécurité) par la suite. Un pirate n'a besoin que d'une porte dérobée à exploiter pour voler des données, et renoncer à l'élément humain dans le contrôle de la qualité et de la sécurité peut avoir des conséquences désastreuses.

Le "juste milieu" consiste à s'assurer que vous disposez d'un équilibre entre les personnes et les outils. Les outils doivent servir d'assistants à une équipe en qui vous avez confiance pour atteindre les objectifs du projet. Vous devez :

• Allouez suffisamment de temps pour que les personnes se familiarisent avec la chaîne d'outils DevOps choisie.
• L'accent est mis sur une collaboration efficace (et sur la manière dont les outils peuvent la soutenir).
• Remédier à toute lacune dans le processus, qu'il s'agisse de compétences/connaissances ou d'outils.

En bref, ne vous contentez pas de vous équiper et d'espérer que tout ira bien.

DevOps n'est pas un mot à la mode, c'est une culture. Êtes-vous en train de développer la vôtre ?

La gestion du changement est difficile dans le meilleur des cas. La peur de l'inconnu peut empêcher même les membres les plus brillants de l'équipe de développer leurs compétences et d'élargir leurs horizons.

Vous voyez, il ne suffit pas de dire "faisons du DevOps" et de faire changer l'équipe des opérations de bureau pour mettre en œuvre un processus réussi comme par magie. Beaucoup seront désorientés et les membres de longue date de l'équipe seront mécontents. La communication des attentes est cruciale, tout comme le fait de "joindre le geste à la parole". DevOps représente un mouvement culturel tout autant qu'une méthodologie de développement, et une équipe doit vivre et respirer un état d'esprit transversal et collaboratif.

À quoi ressemble une grande culture DevOps ?

• Les individus sont habilités à apporter leur expertise à un processus, et pas seulement les dirigeants.
• Une communication ouverte, honnête et respectueuse entre les équipes
• Chaque personne assume la responsabilité de l'objectif global d'intégration de la qualité et de la sécurité dans le processus de développement.
• Tout le monde est sur la même longueur d'onde en ce qui concerne la définition de DevOps dans l'entreprise, la feuille de route et le comment/quoi/pourquoi du rôle de chacun.

Depuis des années, j'insiste sur l'importance de créer des cultures de sécurité positives dans les équipes de développement, et DevOps n'est pas différent.

Il est impératif de disposer des bons outils, des bonnes connaissances et du bon soutien pour mettre en œuvre les meilleures pratiques en matière de sécurité, constater une baisse des vulnérabilités découvertes et ouvrir les yeux de l'équipe sur l'importance de la protection de nos données. Avec DevOps, vous devez jeter les bases culturelles d'un changement positif : veillez à ce que chacun comprenne son rôle, sa valeur et ses attentes, les objectifs globaux du projet et les étapes du processus.

Vous avez maîtrisé cela ? C'est parfait. Maintenant, déplaçons l'aiguille, augmentons l'aspect sécurité et faisons de DevSecOps le plan ultime pour l'excellence logicielle.

Le 11 juin 2019, le National Institute of Standards & Technology(NIST) a publié un livre blanc mis à jour, détaillant plusieurs plans d'action pour réduire les vulnérabilités des logiciels et les cyber-risques. Intitulé Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF), le NIST fournit aux organisations des lignes directrices solides pour éviter les conséquences désagréables - pour ne pas dire coûteuses - d'une violation de données.

Il est important de noter que le SSDF est délibérément générique, il ne suppose pas que chaque organisation a exactement les mêmes objectifs en matière de sécurité des logiciels, et il ne prescrit pas non plus de mécanisme précis pour les atteindre. L'objectif principal est de mettre en œuvre les meilleures pratiques en matière de sécurité. Comme l'indique l'auteur, Donna Dodson : "Bien que l'on souhaite que chaque producteur de sécurité suive toutes les pratiques applicables, on s'attend à ce que le degré de mise en œuvre de chaque pratique varie en fonction des hypothèses de sécurité du producteur. Les pratiques offrent une certaine souplesse aux responsables de la mise en œuvre, mais elles sont également claires afin de ne pas laisser trop de place à l'interprétation".

Ce qui m'a particulièrement intéressé, bien sûr, ce sont les inclusions spécifiques concernant la formation à la sécurité des logiciels pour les développeurs. Nous savons depuis longtemps que les développeurs ont besoin d'une formation adéquate s'ils veulent défendre une organisation dès le début du processus de développement de logiciels... mais qu'est-ce qui est adéquat, exactement ? Il existe de nombreuses opinions divergentes. Cependant, je pense que l'enveloppe est enfin poussée dans une direction qui produira des résultats positifs significatifs.

Il y a la formation à la sécurité... et il y a la formation à la sécurité efficace.

J'ai longuement parlé de la nécessité d'une mise en œuvre plus efficace de la formation à la sécurité des logiciels, d'un engagement et d'une adaptation aux besoins du développeur. Aujourd'hui encore, dans de nombreuses organisations, il s'agit au mieux d'un exercice de type "cocher la case". Il y a peut-être quelques heures de formation vidéo, ou même du temps précieux passé hors des outils pour un apprentissage en classe. Le fait qu'il y ait des violations de données à grande échelle tous les deux jours, perpétrées par des attaquants qui exploitent des vulnérabilités bien connues (et généralement facilement corrigées), prouve que la formation à la sécurité des logiciels est loin d'être aussi efficace qu'elle devrait l'être. Et, ce qui est peut-être le plus important, il existe très peu de moyens de vérifier l'efficacité de la formation : les vulnérabilités sont-elles corrigées plus rapidement ? Les personnes ont-elles réellement suivi la formation ou ont-elles simplement cliqué sur "suivant" pour la terminer ?

Les développeurs sont des gens très occupés, qui travaillent dur pour respecter des délais stricts. La plupart du temps, la sécurité est un inconvénient, et il est rare que leur formation leur apporte les connaissances nécessaires pour atténuer les cyberrisques. Le mot "sécurité" est généralement prononcé lorsqu'un membre de l'équipe AppSec signale des failles dans leur travail, ce qui crée une relation plutôt froide et dysfonctionnelle. Un scénario du type "votre bébé est moche, allez le réparer".

Qu'est-ce que cela nous apprend ? C'est un signal d'alarme vieux de plusieurs décennies qui montre que nous ne faisons pas assez pour convaincre les développeurs de la nécessité de la sécurité ; ils ne sont pas motivés pour prendre des responsabilités, ni pour rechercher les outils dont ils ont besoin pour créer des logiciels fonctionnels, tout en gardant à l'esprit les meilleures pratiques en matière de sécurité.

Les développeurs sont intelligents, créatifs et aiment résoudre des problèmes. Il est peu probable que regarder d'interminables vidéos sur les vulnérabilités en matière de sécurité les passionne ou les aide à rester engagés. En tant qu'instructeur SANS, j'ai très vite appris que la meilleure formation est pratique, les obligeant à analyser et à être défiés intellectuellement, en utilisant des exemples du monde réel qui mettent leur cerveau à l'épreuve et s'appuient sur leurs connaissances antérieures. 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 l'application.

Les lignes directrices du NIST précisent "Fournissez une formation spécifique à chaque rôle à l'ensemble du personnel dont les responsabilités contribuent à un développement sécurisé. Révisez périodiquement la formation spécifique au rôle et mettez-la à jour si nécessaire." Plus loin, elles précisent : "Définir les rôles et les responsabilités du personnel chargé de la cybersécurité : "Définissez les rôles et les responsabilités du personnel chargé de la cybersécurité, des champions de la sécurité, des cadres supérieurs, des développeurs de logiciels, des propriétaires de produits et des autres personnes impliquées dans le cycle de développement durable.

Cette déclaration, bien qu'elle ne soit pas spécifique au type de formation, contribue à faire évoluer les organisations vers la gauche et à maintenir les meilleures pratiques en matière de sécurité au premier plan. Elle renvoie à l'entreprise la responsabilité de trouver des solutions de formation efficaces et plus spécifiques, ce qui, espérons-le, permettra aux développeurs d'être armés des bons outils et des bonnes connaissances pour réussir.

La culture : le chaînon manquant.

Même si une organisation consacre du temps et des ressources à la formation des développeurs et d'autres membres clés du personnel, en mettant l'accent sur leur rôle dans la prévention des vulnérabilités et la réduction des risques de sécurité, ces efforts peuvent souvent être réduits à néant si la culture de sécurité de l'organisation reste fondamentalement défaillante.

Lorsque les individus sont formés efficacement, que les objectifs sont fixés et que les attentes sont claires, il leur est beaucoup plus facile de comprendre leur place dans le paysage de la sécurité et d'assumer les responsabilités qui s'imposent. Dans le cas des développeurs en particulier, ils reçoivent les outils et les connaissances nécessaires pour écrire du code sécurisé dès le début. Toutefois, la meilleure façon d'y parvenir est d'instaurer un environnement de sécurité positif, où il y a moins de double manipulation, de pointes de doigt et de travail en silo sur les projets.

La sécurité doit être au centre des préoccupations de l'ensemble de l'organisation, avec un engagement de soutien et de collaboration pour fournir des logiciels sûrs et de qualité. Cela signifie que les budgets sont suffisants pour mettre en place des formations amusantes et attrayantes qui utilisent des vulnérabilités de code réelles, et que l'ensemble de l'organisation adhère à ces formations pour maintenir l'élan. Dans ce paysage numérique en constante évolution, la formation doit être aussi continue que la livraison. Si l'on vous a dit par le passé qu'une formation à la conformité "unique" ou "à mettre en place et à oublier" était suffisante ou efficace, c'est une erreur.

Bien que le nouveau cadre du NIST n'énonce pas spécifiquement l'obligation d'entretenir une culture de sécurité positive, l'adhésion à ses lignes directrices en nécessitera très certainement une. Il indique toutefois que les organisations doivent "définir des politiques qui précisent les exigences de sécurité auxquelles doivent répondre les logiciels de l'organisation, y compris les pratiques de codage sécurisées que doivent suivre les développeurs".

Ce qui précède est essentiel pour développer et affiner les compétences en matière de sécurité au sein des équipes, et il peut être utile de prendre en compte les éléments suivants lors de l'évaluation de vos propres politiques et du climat actuel en matière d'AppSec :

• Les lignes directrices et les attentes en matière de sécurité des logiciels sont-elles clairement définies ?
• Chacun est-il conscient du rôle qu'il joue dans la réalisation de ces objectifs ?
• La formation est-elle fréquente et évaluée ?
• Vos développeurs sont-ils conscients du rôle considérable qu'ils peuvent jouer dans l'élimination des bogues de sécurité courants avant qu'ils ne se produisent ?

Comme je l'ai dit, cette dernière partie dépend en grande partie de l'organisation et de la formation qu'elle choisit. Elle doit être pertinente, fréquente et engageante. Trouvez une solution qui peut être appliquée à leur travail quotidien et développez leurs connaissances de manière contextuelle.

Et maintenant ?

Il faut vraiment tout un village pour créer, vérifier et déployer les logiciels sécurisés à toute épreuve dont la plupart des entreprises ont besoin, de la manière la plus sûre possible. Il ne s'agit pas seulement de formation. Il existe des lignes directrices à prendre en compte lors de l'utilisation de logiciels tiers(l'utilisation de composants présentant des vulnérabilités connues figure toujours dans le Top 10 de l'OWASP, après tout), des suggestions concernant la vérification, les tests de pénétration et l'examen du code, ainsi que des lignes directrices concernant la tenue des registres de sécurité, les chaînes d'outils appropriées et tout le reste. Gary McGraw, qui est référencé dans le document du NIST .

Toutefois, la victoire la plus rapide peut être obtenue si vos développeurs disposent des bons outils et des bonnes connaissances pour réussir à créer des logiciels sécurisés dès le départ. Il est moins coûteux pour l'entreprise (et plus rapide dans l'ensemble) d'empêcher les vulnérabilités courantes d'apparaître à des stades ultérieurs du cycle de développement logiciel, encore et encore. Jouez avec leurs forces et offrez-leur une incitation à s'impliquer dans la sécurité de l'organisation. Cela peut vraiment être amusant, et ils peuvent être les héros juste à temps dont vous avez besoin pour garder les méchants à l'extérieur, et nos données en sécurité.

Références :

1. ATTÉNUER LE RISQUE DE VULNÉRABILITÉ DES LOGICIELS EN ADOPTANT UN SSDF (11 JUIN 2019), Page 2.
2. ATTÉNUER LE RISQUE DE VULNÉRABILITÉ DES LOGICIELS EN ADOPTANT UN SSDF (11 JUIN 2019), Page 5.
3. ATTÉNUER LE RISQUE DE VULNÉRABILITÉ DES LOGICIELS EN ADOPTANT UN SSDF (11 JUIN 2019), Page 4.

Au début du mois, j'ai eu l'occasion d'assister à l 'OWASP AppSec Day 2019 dans la belle ville de Melbourne. Ces événements axés sur les développeurs sont parmi mes préférés du calendrier ; ils fournissent un rappel humble de la communauté qui travaille sans relâche pour éduquer et habiliter les ingénieurs logiciels et les spécialistes à défendre la sécurité dans leur travail.

La liste des invités était sensationnelle - sans parler de la diversité rafraîchissante - et c'est un grand sentiment que, même après toutes ces années dans l'industrie, je peux moi aussi repartir inspiré. Tanya Janca, Toni James et Teri Radichel ont fait des présentations incroyables, tandis que Wireghoul'Eldar Marcussen a lancé des défis de codage sécurisé qui ont mis à l'épreuve l'ensemble de l'auditoire.

Cette année, Secure Code Warrior était un sponsor platine de l'événement. J'ai dû sourire en me rappelant qu'il y a quatre ans à peine, c'était l'équipe de l'OWASP AppSec Day qui aidait notre jeune entreprise en lui offrant un stand gratuit et une promotion. C'était un moment de fierté de voir le chemin parcouru en tant qu'entreprise, et un moment de reconnaissance de l'existence d'une communauté aussi généreuse de personnes incroyables.

Toni James : La sécurité du point de vue du développeur

S'il est une chose que nous devons cultiver davantage dans ce monde, c'est l'empathie. Et lorsqu'il s'agit de rendre les logiciels plus sûrs, il est essentiel de comprendre le sort des développeurs.

J'ai vraiment apprécié la présentation de Toni, et je suis sûr qu'elle a été immédiatement compréhensible pour tous les développeurs. L'histoire ne se résume pas à "écrire du code sécurisé", et bien que je sois convaincu que les développeurs efficacement formés à la sécurité sont notre meilleure chance dans la lutte contre les vulnérabilités, il est impératif de prendre en compte les défis quotidiens qu'ils rencontrent.

Le travail d'un développeur de logiciels peut être présenté à des millions d'utilisateurs, soutenir des infrastructures critiques et être la force motrice de services que nous considérons comme acquis. L'élaboration de fonctionnalités, la mise en œuvre d'innovations commerciales et le respect de délais de livraison serrés créent beaucoup de pression, et ce avant qu'une équipe AppSec ne s'immisce et ne réduise en miettes leur dur labeur. Toni a parlé de la vie dans cet environnement et de la manière dont une bonne dose d'empathie de part et d'autre peut conduire à de bien meilleurs processus et à de meilleurs résultats en matière de sécurité. Je suis très heureux de voir que des progrès aussi importants sont réalisés pour combler le fossé entre les développeurs et les équipes AppSec ; en fin de compte, il s'agit d'un élément essentiel pour une culture de sécurité positive et florissante, et Toni est un excellent exemple de ce processus qui fonctionne incroyablement bien.

Tanya Janca et Teri Radichel : les super-héros de la sécurité

Non pas qu'il s'agisse d'une compétition, mais les contributions de Tanya Janca et Teri Radichel à la conférence ont été parmi mes préférées. Dix minutes après le début de leur tutoriel sur les évaluations bricolées de la sécurité dans le nuage ont révélé l'étendue de leur expérience, de leurs qualifications et de leur expertise, mais aussi leur chaleur authentique et leur désir de partager leurs connaissances et de soutenir la communauté des développeurs. Ensemble, ils ont présenté des actions réalistes et exécutables pour garantir la sécurité des implémentations Azure, y compris des conseils pratiques sur la définition de politiques de sécurité et de mesures de moindre privilège.

Une recherche rapide sur Google vous dira tout ce que vous devez savoir sur leur dévouement à soutenir les développeurs à la base, avec une multitude de ressources gratuites, d'opportunités de mentorat et d'interviews pour promouvoir le côté amusant et engageant de la sécurité des logiciels. S'ils interviennent lors de la prochaine conférence sur la sécurité à laquelle vous assisterez, vous seriez bien en peine de manquer leur session.

Les clients sur la grande scène

C'était formidable de voir tant de nos clients non seulement présents, mais aussi maîtres de la scène et partageant leurs immenses connaissances en matière de sécurité avec l'auditoire.

Nous avons réussi à voir Andrew Bailey, de Telstra, donner une conférence importante, "Adding the Sec'to DevOps" (ajouter la sécurité à DevOps). Sa riche expérience en tant qu'ingénieur logiciel senior, désormais focalisée sur la sécurité des applications et le codage sécurisé, était un excellent point de vue à mettre en avant. Il a donné des conseils de bout en bout sur l'injection de la sécurité à chaque étape du SDLC (y compris, bien sûr, dès le début en formant davantage de développeurs au codage sécurisé).

Ken Johnson fait partie de l'équipe de sécurité de GitHub, et j'ai été ravi de le voir rejoindre le panel d'experts à la fin de la conférence. Avec les autres panélistes, il n'était que trop heureux de répondre aux questions pressantes du public, y compris celles qui ne reçoivent pas nécessairement l'attention qu'elles méritent dans les médias. En plus de plusieurs idées sur l'industrie, il a fait parler le panel sur l'importance du bien-être et de l'équilibre entre le travail et la vie privée, ce qui est très important à l'heure du burn-out des développeurs.

J'aimerais remercier Julian Berton et toute l'équipe de l'OWASP Melbourne pour une autre conférence incroyable. Rendez-vous l'année prochaine (avec plus d'autocollants).

On a l'impression que la "conformité en matière de cybersécurité" est à la mode depuis des années, avec une multitude d'articles, d'initiatives et de comités qui discutent de la meilleure façon de s'attaquer à l'énorme bête aux multiples menaces qu'est la cybercriminalité.

Le problème, c'est que nous ne semblons pas avoir fait beaucoup de progrès. À l'échelle mondiale, le coût des violations de données n'a cessé de croître, augmentant de 12 % en cinq ans pour s'établir à environ 3,92 millions de dollars américains par violation en 2019. Alors que notre utilisation d'Internet a explosé en l'espace de quelques décennies, de nombreuses entreprises ont dû se battre sans armure pour se mettre rapidement en ligne, ouvrir leur boutique et faire face aux conséquences de logiciels non sécurisés, de ressources AppSec limitées et, dans certains cas, d'un abus de confiance de la part de leurs clients.

Aujourd'hui, nous sommes incontestablement plus mûrs. Nous comprenons l'ampleur de la menace et en discutons longuement, les entreprises sont bien conscientes de l'impact qu'une cyberattaque peut avoir sur le sentiment des clients, leur réputation et leurs résultats, et de nombreux endroits cherchent activement à améliorer la sécurité des logiciels par le biais de formations sur la conformité, d'embauches qualifiées et, de plus en plus, d'initiatives DevSecOps. Malgré ces progrès considérables, nous ne sommes pas en train de gagner la bataille, loin s'en faut. Rien qu'en 2019, au moins quatre milliards d'enregistrements ont été volés dans le cadre de violations de données.

L'ingrédient manquant a été la lenteur de la diffusion (au niveau gouvernemental) des normes de cybersécurité, des attentes et des conséquences d'une violation. Avec l'avènement du GDPR , certaines têtes ont commencé à tomber, du moins en Europe, mais de nombreux organismes gouvernementaux ne font que rattraper leur retard, et la nécessité soudaine de se conformer rapidement à des initiatives de conformité nouvellement apparues pourrait avoir des effets indésirables à l'avenir.

Les imbéciles se précipitent (vers la mauvaise formation)

Des lignes directrices solides sous la forme du NIST, de nouvelles réglementations pour l'État de New York et la formation du Conseil de la cybersécurité du Royaume-Uni sont autant de victoires monumentales pour ceux qui se battent pour assurer la sécurité de nos données. Elles reconnaissent les problèmes liés au développement actuel des logiciels et prennent des mesures pour guider les organisations sur les normes qu'elles doivent désormais respecter pour être considérées comme éthiques et conformes, en termes de meilleures pratiques de sécurité.

Malheureusement, à ce stade, certains des éléments les plus importants sont un peu trop ouverts à l'interprétation. Par exemple, l'un des mandats de la législation du Conseil britannique de la cybersécurité est le suivant :

"Créer une liste définie de certifications et un cadre facile à comprendre sur la manière dont elles s'articulent entre elles et sur les capacités qu'elles véhiculent, en s'appuyant sur le travail déjà entrepris en matière de parcours de carrière.

Il ne fait aucun doute que leurs initiatives s'amélioreront et se développeront au fil du temps, mais si les organisations appuient déjà sur le bouton de panique et se lancent dans la formation dès maintenant, elles risquent de se retrouver mal équipées pour l'avenir.

Les exigences d'une organisation en matière de cybersécurité évoluent rapidement, et il est peu probable que des solutions de formation statiques puissent endiguer le flux de logiciels non sécurisés au rythme requis. Le paysage change plus vite qu'un cours traditionnel ne peut être mis à jour, ce qui fait que certains endroits tombent dans le piège de l'exercice de conformité "tick-the-box" ; les développeurs, les sous-traitants et les autres professionnels de la sécurité ne reçoivent pas de formation adéquate, et nous nous retrouvons à nouveau dans une situation d'attente.

La formation statique et les outils statiques souffrent des mêmes problèmes

Les outils d'analyse statique font partie intégrante du cycle de développement du logiciel (SDLC). Ils jouent le rôle de cheval de bataille pour les spécialistes AppSec, rares et surchargés de travail, que l'on trouve dans la plupart des grandes organisations. Ils font du bon travail, mais il y a un défaut : aucun outil ne peut analyser toutes les vulnérabilités, en prenant en charge l'énorme gamme de cadres de programmation existants. C'est également un processus lent, et il suffit qu'un seul bogue de sécurité passe à travers les mailles du filet pour laisser une porte ouverte à un attaquant.

La formation statique pose un problème similaire. Si les développeurs reçoivent une formation à la sécurité sous la forme d'un cours rigide et unique, il est très peu probable qu'elle ait suivi l'évolution des problèmes de sécurité les plus courants au cours de cette période. Il s'agit d'un instantané de l'époque où il a été écrit, et il est rarement revisité suffisamment, dispensé dans le langage et le cadre préférés de l'étudiant, et il n'est pas contextuel aux vulnérabilités auxquelles il est susceptible d'être confronté dans son travail de tous les jours. Imaginez que vous essayez de vous souvenir d'une information pertinente tirée d'une vidéo que vous avez regardée il y a plusieurs mois, tout en essayant de respecter les délais de livraison et de sortir le code de la porte... Il est peu probable que cela se produise.

Les méthodes d'enseignement traditionnelles sont en train d'être réévaluées dans de nombreux secteurs, mais en ce qui concerne la formation à la sécurité pour les développeurs, il suffit d'observer le volume considérable de violations de données que nous subissons encore (en particulier celles qui peuvent être imputées à des vulnérabilités que nous savons éviter en codant depuis des décennies, comme l'injection SQL) pour se rendre compte qu'il faut essayer une méthode différente.

Nous avons besoin d'une formation qui dépasse les limites d'un cours unique et linéaire et qui puisse s'adapter aux besoins en constante évolution des meilleures pratiques en matière de cybersécurité.

L'entraînement dynamique : la référence

En offrant aux développeurs une solution de formation dynamique, qui peut être adaptée rapidement à l'entreprise, au niveau de compétence individuel et aux mouvements généraux du secteur, vous leur fournissez les meilleures bases pour coder en toute sécurité, en gardant la sécurité à l'esprit et en agissant avec un état d'esprit conscient de la sécurité.

Une formation unique, qui n'est jamais réexaminée et qui n'est pas attrayante dès le départ, sera une véritable perte de temps, ce qui signifie malheureusement que vous pourriez finir par acheter un programme inefficace par souci de conformité. Il pourrait être dépassé avant même que vous ne le mettiez en place, ou à peine en rapport avec les besoins de leur travail quotidien.

La formation dynamique est un outil vivant, mis à jour en permanence, adapté aux besoins quotidiens, qui incite les utilisateurs à la réflexion critique et leur donne réellement les moyens d'acquérir des compétences et de résoudre des problèmes.

Alors, à quoi ressemble un programme de formation dynamique dans un contexte de sécurité ?

Ce sera le cas :

• De la taille d'une bouchée: Les développeurs peuvent acquérir des compétences en morceaux gérables qui sont bien plus faciles à mémoriser (et surtout à appliquer) que les longs dossiers de formation et les vidéos.
• C'est une question pertinente : Quelle est l'utilité d'une formation générique à la sécurité dont les exemples sont, par exemple, en C#, alors que le développeur code principalement en Java ? Toute formation devrait s'appliquer directement à son rôle, lui permettant de voir ce qu'il doit trouver et corriger (et, idéalement, éviter en premier lieu) lorsqu'il code.
• Actuel : Cela semble évident, mais ne l'est pas toujours. Le paysage de la cybersécurité évolue sans cesse, et l'augmentation du nombre de codes entraîne une plus grande responsabilité. Pour que les développeurs soient votre première ligne de défense, ils ont besoin d'une formation qui reste à jour avec les meilleures pratiques de sécurité modernes.
• Engageant : Ce n'est un secret pour personne que les développeurs peuvent trouver que la "sécurité" est une corvée, surtout si elle interfère avec leur flux créatif. Une formation adaptée leur montrera le pouvoir qu'ils détiennent dans la résolution des problèmes de sécurité quotidiens qui peuvent se transformer en risques énormes, en instaurant une culture de la responsabilité et de la sensibilisation à la sécurité.
• Amusant : La formation dynamique est rarement ennuyeuse ; elle est censée être au moins quelque peu excitante de par sa conception. Pensez à ce que les développeurs aiment : résoudre des problèmes, se mesurer à leurs pairs et, comme beaucoup d'entre nous dans le monde du travail, obtenir des récompenses et de la reconnaissance. Jouez sur leurs points forts et concentrez-vous sur l'obtention des meilleurs résultats.

L'époque est passionnante pour les ingénieurs en logiciel : ils jouent un rôle essentiel dans l'innovation numérique, contribuent à la création d'entreprises extraordinaires et peuvent même prendre le monde d'assaut avec leurs propres créations. Cependant, les organismes gouvernementaux et les grandes entreprises ayant pris conscience du rôle qu'ils doivent jouer dans l'établissement de normes en matière de sécurité des logiciels, il est important de les soutenir par des solutions de formation efficaces et dynamiques qui favorisent l'amour du codage sécurisé, et non pas un exercice bureaucratique consistant à cocher des cases.

L'expression "il faut un village" est un vieux proverbe africain qui s'applique à de nombreuses cultures, dialectes et lieux géographiques africains. Si le langage utilisé pour transmettre cette perle de sagesse peut être différent, le sentiment est le même : il faut la contribution de toute la communauté pour créer un environnement sûr, positif et instructif afin d'élever les générations futures et d'en faire des adultes équilibrés.

Cela peut sembler un peu long, mais en réalité, la communauté des développeurs a prospéré pendant des décennies grâce à ce même principe. La notion de geek antisocial, "loup solitaire" derrière un ordinateur est comme la plupart des stéréotypes : exagérée et ce n'est pas la meilleure façon d'apprendre comment nous fonctionnons. Il y a des développeurs de tous types, de tous horizons, et il y a toujours eu un sens de la communauté dans tout ce que nous faisons.

Bien avant que l'internet ne devienne la norme, nous nous retrouvions sur des tableaux d'affichage pour échanger des conseils, résoudre les problèmes des uns et des autres et nous chamailler sur les meilleures pratiques (et, en tout cas de mon côté de la barrière, travailler dur pour casser des choses). Ce sentiment n'a pas changé. L'internet est aujourd'hui une bête différente, avec plus de trolls sous les ponts et beaucoup plus de bruit, mais un saut rapide sur des sites comme Reddit et Stack Overflow vous donnera un sentiment immédiat de volonté d'aider, de camaraderie et d'une richesse d'informations.

Cependant, il y a une chose que nous pourrions tous aider à soutenir, ce sont les liens avec les personnes qui vivent la même chose que vous dans le monde réel. L'interaction dans le monde réel revêt une nouvelle dimension et l'animation d'une communauté "IRL" peut accélérer le partage des connaissances, la clarification et l'élargissement des horizons de manière merveilleuse.

Comment la communauté des développeurs soutient-elle la sécurité ?

Des organisations comme l'OWASP font un travail incroyable dans la communauté de la sécurité, avec d'abondantes ressources gratuites sur les vulnérabilités, les nouvelles et les alertes critiques. Hors ligne, il existe des chapitres de l'OWASP dans des villes du monde entier, qui organisent régulièrement des événements permettant aux gens de se réunir, de parler de sécurité et de partager des astuces pour rendre nos logiciels plus sûrs. C'est vraiment génial, et pour moi, c'est ce qu'est la communauté de développement.

L'une des choses que ces communautés, qu'elles soient en ligne ou en personne, aident à combler est le manque de compétences et de connaissances parmi les développeurs. De nombreux développeurs expérimentés ne sont que trop heureux de transmettre des informations, d'aider quelqu'un à démarrer ou de l'orienter dans la bonne direction (tout bon Jedi sait qu'il doit aider un Padawan de temps en temps).

C'est donc toujours un véritable plaisir lorsque nous nous associons à eux pour organiser des événements tels que Secure Coding tournaments. Jusqu'à présent, nous avons soutenu des rencontres en Australie, en Angleterre, en Inde et aux États-Unis, et j'espère qu'il y en aura encore beaucoup d'autres.

À quoi ressemble une réunion OWASP tournament ? Regardez cette vidéo d'une réunion OWASP tournament qui s'est tenue à Londres dans les studios emblématiques de la BBC :

Ces événements contribuent certainement à la sensibilisation, et cet élan peut être utilisé au sein des organisations lorsqu'elles soutiennent ces initiatives locales, introduisent une formation complète au codage sécurisé, et s'engagent à opérer avec une culture de sécurité positive.

Comment la gamification et le site tournaments peuvent-ils aider à créer des développeurs plus sûrs ?

Les rencontres de l'OWASP sont construites autour de la socialisation, du partage des connaissances et de la discussion d'idées avec un large éventail de personnes sensibilisées à la sécurité. Cependant, pour ceux qui ne connaissent pas la sécurité (ou qui ne s'y intéressent pas encore), ces événements peuvent passer inaperçus.

Lorsque les organisations jouent un rôle actif dans la sensibilisation à la sécurité et suscitent un réel intérêt au sein de la cohorte des développeurs, cela peut avoir pour effet positif d'instiller une quête permanente de connaissances en matière de sécurité - le type de connaissances dont nous avons besoin pour que tout le monde prenne au sérieux la sécurité du codage.

Les méthodes de formation classiques sont rarement très motivantes (pensez à vous asseoir dans une salle de classe pendant que vos tâches quotidiennes s'accumulent, ou à essayer de rester éveillé en regardant d'interminables vidéos), mais en suscitant un sentiment de compétition, d'amusement et de gamification du processus, l'apprentissage peut devenir beaucoup moins une corvée. Les méthodes d'apprentissage par le jeu rendent les connaissances techniques (et parfois arides) beaucoup plus digestes, en les divisant en petits morceaux qui sont contextuels, mémorisables et encouragent l'apprentissage répété. Secure Code Warrior a été construit sur une base d'accessibilité, permettant aux développeurs de continuer à ajouter à leurs apprentissages précédents étape par étape, d'une manière qui fait appel à leur créativité et à leur instinct général pour résoudre les problèmes.

Les évaluations aident à maintenir tout le monde sur la bonne voie et à identifier les domaines à améliorer, mais un codage sécurisé tournament peut servir de catalyseur pour la sensibilisation à la sécurité de l'organisation et le changement positif, ainsi que de moyen pour les participants de montrer leurs solides compétences. Après tout, lorsque vous voyez un tableau de classement tournament mis à jour en temps réel, vous êtes motivé pour continuer à gagner des points et à montrer vos prouesses en matière de sécurité.

À quoi ressemble un site tournament réussi ?

L'objectif de nos rencontres avec l'OWASP est toujours d'investir dans la santé de la communauté de la sécurité, en l'aidant à promouvoir l'idée que l'apprentissage de la sécurité peut être amusant.

Secure coding tournaments est une évidence lorsqu'il s'agit d'impliquer les développeurs, en les aidant à affiner et à réaliser leurs compétences dans un environnement social avec des personnes partageant les mêmes idées. Ils contribuent à briser les murs artificiels qui peuvent exister autour de l'idée de "sécurité", peut-être à la suite d'une expérience moins que plaisante au travail ou dans l'éducation.

Un vrai bon site tournament comprend généralement les éléments suivants :

• Un peu de fanfare autour de l'organisation ; faites savoir aux personnes extérieures aux équipes de développement ce qui se passe et pourquoi.
• Un environnement exempt de jugement, qui soutient les développeurs à tous les niveaux
• Quelques avantages particuliers : commandez de la nourriture et des boissons, donnez un thème et encouragez l'expression personnelle.
• Récompenses et reconnaissance : nous, les développeurs, aimons les cadeaux, et les prix intéressants pour les gagnants sont un bonus : n'oubliez pas que vos futurs champions de la sécurité pourraient être découverts au cours de ce processus.
• Un sens de la communauté et de la camaraderie.

Nous sommes en train de devenir un monde DevSecOps, et comme la sécurité est enfin prise en compte dès le début des projets de développement de logiciels, les développeurs doivent être impliqués très tôt grâce à une formation efficace. Ils font partie intégrante de la protection d'une organisation contre les vulnérabilités dès le moment où le code est écrit, et dans une culture de sécurité florissante, tout le monde peut dormir un peu plus tranquille.