Sommes-nous assez matures pour le plan de mobilisation pour la sécurité des logiciels open source ?

Dans le contexte économique et le paysage des menaces actuels, je n'envie certainement pas le RSSI moyen. Il a pour mission d'assurer la sécurité, la conformité, l'innovation et la valeur commerciale, tout en faisant face à une bataille difficile contre des budgets en baisse et une surveillance accrue. Plus urgent encore, chaque organisation (et son équipe de développement respective) se situe à des stades de maturité de sécurité différents, et toutes ne sont pas équipées pour donner le meilleur d'elles-mêmes en matière de cyberdéfense.

Les quelques dernières années marquées par l'escalade des incidents de cybersécurité ont rendu la tâche très difficile aux responsables de la sécurité pour garder une longueur d'avance. Un simple coup d'œil à certaines données sur notre situation préoccupante révèle une véritable poudrière : 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 coût de la cybercriminalité devrait atteindre 10 500 milliards 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 USD (bien qu'il suffise de regarder des incidents comme Equifax ou Solar Winds pour voir que cela peut être bien pire).

En tant qu'industrie, nous avons attendu longtemps qu'un héros vienne nous sauver des méchants de la cybersécurité qui semblent détenir plus de pouvoir que nous ne l'aurions cru possible, même il y a dix ans. Nous attendons que davantage de professionnels de la cybersécurité nous rejoignent pour nous élever vers un standard de programme de sécurité plus élevé, mais c'est un fossé que nous ne pouvons pas combler. Nous attendons la solution miracle qui nous promet d'automatiser la gestion des risques croissants, mais elle n'existe pas et il est très peu probable qu'elle existe un jour. Nous attendons notre Luke Skywalker pour nous aider à combattre le Côté Obscur.

Il s'avère que de l'aide (et de l'espoir) arrive, sous la forme du Plan de mobilisation pour la sécurité des logiciels open source. 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 les compétences nécessaires en matière de sécurité — pour mettre en œuvre les stratégies de défense les plus récentes et les plus performantes, surtout lorsqu'elles nécessitent le soutien et l'exécution par l'équipe de développement.

Qu'est-ce que le Plan de mobilisation pour la sécurité des logiciels open source ?

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, des RSSI de premier plan et d'autres dirigeants de 37 entreprises technologiques privées. Grâce à ce soutien combiné en termes d'action et de financement, le niveau de sécurité des logiciels open source est appelé à devenir beaucoup plus robuste.

Ce qui est particulièrement intéressant, c'est l'accent mis sur l'éducation de base et la certification au niveau des développeurs, ainsi que sur les mesures conçues pour rationaliser les activités internes liées à la nomenclature logicielle (SBOM). Ces éléments sont notoirement difficiles à mettre en œuvre de manière à avoir un impact durable, ce qui peut être attribué en partie aux difficultés de croissance au sein des programmes de sécurité organisationnels, et à un manque général de maturité en matière de sécurité parmi le groupe des développeurs, sans que ce soit de leur faute. Ils évoluent dans un environnement sous pression où le volume de code et la rapidité règnent en maîtres, face à des délais toujours plus déraisonnables. Ajouter encore plus de tâches sous forme de demandes de sécurité et de maintenance de SBOM sans augmenter le temps disponible est une recette qui a échoué avant même d'avoir commencé, et malheureusement, c'est plus courant que nous pourrions le penser.

Alors, regardons sous le capot.

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

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

Si nous examinons le Plan de mobilisation pour la sécurité des logiciels open source, le tout premier volet du plan en dix points concerne les compétences en sécurité des développeurs, afin de « Fournir une éducation et une certification de base en développement logiciel sécurisé à tous », ce qui est essentiel pour renforcer la maturité en matière de sécurité au sein des équipes de développement. Ils soulignent les problèmes dont nous discutons depuis un certain temps, notamment le fait que le codage sécurisé est absent de la plupart des cours d'ingénierie logicielle au niveau universitaire. Il est extrêmement encourageant de voir cela soutenu par des individus et des départements capables de changer le statu quo de l'industrie, et avec 99 % des logiciels mondiaux contenant au moins un peu de code open source, ce domaine du développement est un excellent point de départ pour se concentrer sur la formation des développeurs à la sécurité.

Le plan cite des ressources respectées comme les cours OpenSSF Secure Software Fundamentals, ainsi que les ressources étendues et de longue date de la OWASP Foundation. Ces centres d'information sont inestimables. Le déploiement proposé pour diffuser ces supports afin de faire monter les développeurs en compétences implique de réunir un vaste réseau de partenaires, dans les secteurs public et privé, en plus de collaborer avec des établissements d'enseignement pour faire du développement sécurisé open source une caractéristique clé du programme d'études.

Quant à la manière dont ils vont conquérir le cœur et l'esprit des ingénieurs logiciels du monde entier, dont beaucoup ont intégré l'idée que la sécurité n'est pas leur travail ou leur priorité, le plan détaille une stratégie de récompense et de reconnaissance ciblant à la fois les développeurs qui maintiennent des bibliothèques open source et les ingénieurs en activité qui ont besoin de voir la valeur 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 par niveaux montrant les progrès et les compétences fonctionnent tout aussi bien dans un environnement d'apprentissage que sur des plateformes comme Steam ou Xbox.

Cependant, ce qui est préoccupant, c'est que nous ne traitons pas l'un des problèmes fondamentaux, à savoir la prestation de modules d'apprentissage au sein 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 lorsqu'il s'agit d'outils et de formation, sans parler de tout ce qui semble pouvoir perturber le travail qui est la priorité numéro un. L'autonomisation des développeurs exige qu'ils s'engagent continuellement dans le matériel de cours, et pour que cela réussisse, cela doit avoir du sens dans le contexte de leur travail quotidien.

Si nous considérons un modèle de maturité établi comme le Software Assurance Maturity Model (SAMM), « Éducation et conseils » est une composante essentielle de la couche Gouvernance, et l'accent est mis sur l'éducation des développeurs. Le modèle dans son ensemble est vaste, et il existe des étapes progressives pour atteindre des niveaux de maturité plus élevés. Cependant, les étapes initiales recommandent seulement 1 à 2 jours de formation formelle pour les développeurs, ce qui est à peine suffisant pour effleurer la surface de la sensibilisation à la sécurité. Même dans ce cas, un rapport récent de l'Enterprise Strategy Group (ESG) a révélé que moins de la moitié des organisations exigent des développeurs qu'ils suivent une formation formelle en sécurité plus d'une fois par an. Nos propres recherches menées conjointement avec Evans Data ont révélé que seulement 29 % des développeurs estiment que la pratique active de l'écriture de code exempt de vulnérabilités devrait être priorisée. Il existe un décalage évident entre la manière dont l'éducation est dispensée et reçue, et son utilité réelle pour parvenir à une maturité en matière de sécurité, surtout si les développeurs n'en perçoivent pas la valeur.

Nomenclature logicielle (SBOM) : ce plan permet-il de lever les obstacles à l'adoption ?

Le plan s'attaque également au chaos qui entoure souvent la création et la maintenance des nomenclatures logicielles (SBOM). Le volet « SBOM partout : améliorer les outils et la formation pour favoriser l'adoption » explore des moyens de simplifier pour les développeurs et leurs organisations la création, la mise à jour et l'utilisation des SBOM afin d'améliorer la sécurité.

À l'heure actuelle, les SBOM sont peu utilisés dans la plupart des secteurs, ce qui limite leur potentiel de réduction des risques. Le plan propose une stratégie pertinente pour définir des normes clés de formulation des SBOM et des outils d'intégration fluides pour les développeurs. Cela suffirait à alléger la charge de travail de ceux qui doivent déjà jongler avec de multiples priorités pour produire des logiciels à la vitesse demandée.

Je crains toutefois que, dans une organisation classique, les responsabilités en matière de sécurité ne restent une zone grise pour les développeurs. Qui est responsable ? L'équipe de sécurité, certes, mais les développeurs doivent être impliqués. Les attentes doivent être clairement définies et ils doivent disposer du temps nécessaire pour intégrer ces nouvelles exigences à leurs objectifs.

De l'OSS au reste du monde logiciel

Le plan de mobilisation pour la sécurité des logiciels open source est ambitieux, audacieux et indispensable pour responsabiliser les développeurs. Il a fallu une « Alliance rebelle » d'acteurs influents pour y parvenir, mais cela prouve que nous allons dans la bonne direction et que nous abandonnons l'idée que la pénurie de compétences en cybersécurité se résoudra d'elle-même.

C'est notre nouvel espoir, et il faudra nous unir pour étendre cette structure au-delà de l'OSS. Les professionnels de la sécurité doivent toutefois s'interroger et analyser les équipes de développement dont ils protègent le code. Ils doivent évaluer honnêtement leurs capacités, identifier les lacunes et bâtir un modèle mature, proactif et inclusif, capable de transmettre de réelles compétences en sécurité aux développeurs. Sans une autonomisation concrète, notre approche des vulnérabilités restera immature.

‍

>> Évaluez la maturité de votre équipe en matière de sécurité avec notre défi XSS interactif !