Sommes-nous suffisamment mûrs pour le plan de mobilisation pour la sécurité des logiciels libres ?

Dans le climat économique actuel et le paysage des menaces, je n'envie certainement pas le CISO moyen. Ils sont chargés d'assurer la sécurité, la conformité, l'innovation et la valeur commerciale, tout en faisant face à une rude bataille avec des budgets en baisse et une surveillance accrue. Ce qui est peut-être plus urgent, c'est que chaque organisation (et son équipe de développement respective) se trouve à différents stades de maturité en matière de sécurité et que toutes ne sont pas équipées pour faire de leur mieux en termes de cyberdéfense.

Au cours des dernières années, l'escalade des incidents de cybersécurité a rendu difficile pour les responsables de la sécurité de garder une longueur d'avance. Le simple fait de jeter un coup d'œil à certaines informations fondées sur les données relatives à notre situation croissante révèle une sorte de baril de poudre : plus de 33 milliards d'enregistrements seront volés par des cybercriminels rien qu'en 2023, soit une augmentation de 175 % par rapport à 2018. Le le coût de la cybercriminalité devrait atteindre 10,5 billions de dollars d'ici 2025, et le coût moyen d'une violation de données a grimpé en flèche pour atteindre 4,24 millions de dollars américains (même si nous n'avons qu'à examiner des incidents tels qu'Equifax ou Solar Winds) pour voir que cela peut être bien pire).

En tant qu'industrie, nous attendons depuis longtemps qu'un héros vienne nous sauver des méchants de la cybersécurité qui semblent détenir plus de pouvoir que ce que nous pensions possible, il y a encore dix ans. Nous attendons que davantage de professionnels de la cybersécurité se joignent à nous pour améliorer nos programmes de sécurité, mais nous ne pouvons pas combler cette lacune. Nous attendons la solution d'outillage miracle qui promet de nous automatiser pour nous éloigner des risques croissants, mais elle n'existe pas et il est très peu probable qu'elle existe. Nous attendons que Luke Skywalker nous aide à combattre le Côté Obscur.

Il s'avère que de l'aide (et de l'espoir) est en route, sous la forme de Le plan de mobilisation pour la sécurité des logiciels libres. Cependant, nous devons tous faire le point et évaluer honnêtement si notre organisation est suffisamment mature - et si nos équipes de développement possèdent le niveau de sensibilisation et de compétences en matière de sécurité requis - pour mettre en œuvre les stratégies défensives les plus récentes et les plus performantes, en particulier lorsqu'elles nécessitent le soutien et l'exécution de l'équipe de développement.

Qu'est-ce que le plan de mobilisation pour la sécurité des logiciels libres ?

Ce plan en dix points a été piloté par l'Open Source Software Foundation (OpenSSF) et la Linux Foundation, en collaboration avec des responsables de la Maison Blanche, de hauts responsables de la sécurité informatique et d'autres hauts dirigeants de 37 entreprises technologiques privées. Grâce à ce soutien combiné en termes d'action et de financement, la norme de sécurité des logiciels libres est appelée à devenir beaucoup plus stricte.

Ce qui est particulièrement intéressant, c'est qu'ils mettent l'accent sur la formation de base et la certification au niveau des développeurs, ainsi que sur les mesures conçues pour rationaliser les activités internes de nomenclature des logiciels (SBOM). Elles sont toutes deux notoirement difficiles à mettre en œuvre de manière à avoir un impact durable, ce qui peut être attribué en partie aux difficultés croissantes rencontrées par les programmes de sécurité organisationnels et à un manque général de maturité en matière de sécurité au sein de la cohorte de développement, ce qui n'est pas de leur faute. Ils se trouvent dans un environnement d'autocuiseur où le volume de code à grande vitesse règne en maître, face à des délais de plus en plus déraisonnables. Ajouter encore plus de tâches sous forme de demandes de sécurité et de maintenance du SBOM sans augmenter le temps disponible pour celles-ci est une recette qui a échoué avant même d'avoir commencé et, malheureusement, elle est plus courante que prévu.

Jetons donc un coup d'œil sous le capot.

Certification de sécurité pour les développeurs : y sommes-nous déjà ?

S'il y a une chose dont nous sommes sûrs, c'est que développeurs compétents en matière de sécurité sont encore une denrée rare. C'est la réalité pour plusieurs raisons, notamment parce que, jusqu'à récemment, les développeurs ne faisaient pas partie de l'équation lorsqu'il s'agissait de stratégies de sécurité logicielle au sein des organisations. Ajoutez à cela que les développeurs n'ont aucune raison de donner la priorité à la sécurité (leur formation est inadéquate ou inexistante, elle prend plus de temps, cela ne fait pas partie de leurs KPI et leur principale préoccupation est de faire ce qu'ils font le mieux : créer des fonctionnalités) et vous avez des équipes de développement mal préparées à gérer véritablement la sécurité au niveau du code, ni à jouer leur rôle dans un cycle de vie de développement logiciel (SDLC) modernisé et centré sur DevSecOps.

Si nous examinons le plan de mobilisation pour la sécurité des logiciels libres, le tout premier volet de ce plan en dix points concerne les compétences des développeurs en matière de sécurité, afin de « proposer à tous une formation et une certification de base en matière de développement de logiciels sécurisés », ce qui est essentiel pour renforcer la maturité en matière de sécurité des équipes de développement. Ils mettent en lumière les questions dont nous discutons depuis un certain temps, notamment le fait que le codage sécurisé ne figure pas dans la plupart des cours de génie logiciel du niveau supérieur. Il est incroyablement encourageant de voir que cela est soutenu par des personnes et des départements capables de changer le statu quo du secteur, et avec 99 % des logiciels du monde contiennent au moins quelques code source ouvert, ce domaine du développement est un excellent point de départ pour se concentrer sur la formation des développeurs en matière de sécurité.

Le plan cite des ressources vénérées comme le Principes fondamentaux du logiciel OpenSSF Secure cours et les ressources étendues et de longue date du Fondation OWASP. Ces centres d'information sont d'une valeur inestimable. Le déploiement proposé pour diffuser ces supports aux développeurs de compétences implique la mise en place d'un vaste réseau de partenaires, des secteurs public et privé, ainsi que des partenariats avec des établissements d'enseignement pour faire du développement sécurisé open source un élément clé du programme.

Quant à la manière dont ils vont gagner le cœur et l'esprit des ingénieurs logiciels du monde entier, dont beaucoup ont vu la sécurité renforcée car ce n'est pas leur travail ni leur priorité, le plan détaille une stratégie de récompense et de reconnaissance destinée à cibler à la fois les développeurs gérant des bibliothèques open source et les ingénieurs en activité qui ont besoin de comprendre l'intérêt des certifications de sécurité.

Nous savons par expérience que les développeurs réagissent bien aux incitations et que les systèmes de badges à plusieurs niveaux indiquant les progrès et les compétences fonctionnent aussi bien dans un environnement d'apprentissage que sur Steam ou Xbox.

Cependant, ce qui est préoccupant, c'est que nous ne nous attaquons pas à l'un des problèmes fondamentaux, à savoir la fourniture de modules de formation dans le cadre du programme de sécurité d'une organisation. Ayant travaillé en étroite collaboration avec des développeurs pendant une grande partie de ma carrière, je sais à quel point ils sont sceptiques en ce qui concerne les outils et la formation, sans parler de tout ce qui semble susceptible de perturber le travail qui est la priorité numéro un. L'habilitation des développeurs exige qu'ils s'intéressent en permanence au matériel de cours, et pour que cela soit un succès, cela doit avoir un sens dans le contexte de leur travail quotidien.

Si l'on considère un modèle de maturité établi comme le Modèle de maturité de l'assurance logicielle (SAMM), « Education et orientation » est une composante essentielle de la couche de gouvernance, et l'accent est mis sur la formation des développeurs. Le modèle dans son ensemble est vaste et des étapes progressives sont nécessaires pour atteindre des niveaux de maturité plus élevés. Cependant, les étapes initiales ne recommandent que 1 à 2 jours de formation officielle pour les développeurs, ce qui est à peine suffisant pour une sensibilisation à la sécurité. Même alors, un rapport récent par l'Enterprise Strategy Group (ESG) a révélé que moins de la moitié des entreprises demandent à leurs développeurs de suivre une formation officielle en matière de sécurité plus d'une fois par an. Notre propres recherches en collaboration avec Evans Data, a révélé que seuls 29 % des développeurs pensent que la pratique active consistant à écrire du code sans vulnérabilités devrait être prioritaire. Il existe un décalage évident entre la manière dont la formation est dispensée et reçue, et son utilité réelle pour atteindre la maturité en matière de sécurité, en particulier si les développeurs n'y voient aucun intérêt.

Nomenclature logicielle : ce plan supprime-t-il les obstacles à l'adoption ?

Un autre domaine que le plan cherche à résoudre est la calamité qui entoure souvent la création et la maintenance des nomenclatures logicielles (SBOM), avec le stream « SBOM Everywhere — Improve SBOM Tooling and Training to Drive Adoption » qui étudie les moyens de faciliter la création, la mise à jour et l'utilisation des SBOM pour améliorer les résultats en matière de sécurité pour les développeurs et leurs organisations.

À l'heure actuelle, les SBOM ne sont pas largement adoptés dans la plupart des secteurs verticaux, ce qui rend difficile la réalisation de leur potentiel en matière de réduction des risques de sécurité. Le plan comporte une stratégie brillante pour définir des normes clés pour la formulation des SBOM, ainsi que des outils facilitant la création et adaptés à la façon dont les développeurs travaillent. À elles seules, elles contribueraient grandement à alléger la charge que représente une nouvelle tâche SDLC pour les développeurs qui ont déjà beaucoup à faire pour créer des logiciels au rythme de la demande.

Ce que je crains toutefois, c'est que dans une organisation moyenne, les responsabilités en matière de sécurité ne constituent une véritable zone grise pour les développeurs. Qui est responsable de la sécurité ? En fin de compte, c'est l'équipe chargée de la sécurité, mais les développeurs doivent être impliqués si nous voulons leur aide. Les tâches et les attentes doivent être clairement définies, et ils ont besoin de temps pour prendre en compte ces mesures supplémentaires de leur réussite.

De l'OSS au reste du monde du logiciel

Le plan de mobilisation pour la sécurité des logiciels libres est ambitieux, audacieux et répond exactement à ce qu'il faut pour responsabiliser les développeurs en matière de sécurité. Il a fallu créer une « alliance rebelle » réunissant des acteurs puissants, mais cela prouve que nous allons dans la bonne direction et que nous abandonnons l'idée que le déficit de compétences en cybersécurité se résorbera de lui-même comme par magie.

C'est notre nouvel espoir, et il nous faudra tous faire avancer cette structure au-delà de l'OSS. Cependant, les professionnels de la sécurité doivent regarder en eux-mêmes et analyser les équipes de développement qui travaillent sur le code qu'ils sont chargés de protéger. Ils doivent procéder à une évaluation honnête de leurs capacités actuelles, identifier les lacunes, et s'efforcer de créer un stade avancé de maturité qui soit hermétique, proactif et inclusif, avec un programme qui transmet de véritables compétences en matière de sécurité à la cohorte de développement. Tant qu'elles ne seront pas activées de manière significative, nous serons peut-être encore un peu immatures dans notre approche des vulnérabilités au niveau du code.

‍

>> Testez la maturité de votre équipe en matière de sécurité grâce à notre outil pratique et interactif Défi XSS!