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

Dans le climat économique et le paysage des menaces actuels, je n'envie certainement pas le RSSI moyen. Il est chargé d'assurer la sécurité, la conformité, l'innovation et la valeur de l'entreprise, tout en étant confronté à des budgets réduits et à une surveillance accrue. Ce qui est peut-être encore plus urgent, c'est que chaque organisation (et son équipe de développement) se trouve à des stades différents de maturité en matière de sécurité, et que toutes ne sont pas équipées pour donner le meilleur d'elles-mêmes en termes de cyberdéfense. 

Ces dernières années, les incidents de cybersécurité se sont multipliés et il est devenu difficile pour les responsables de la sécurité de garder une longueur d'avance. Il suffit de jeter un coup d'œil sur les données qui nous renseignent sur notre situation de plus en plus difficile pour se rendre compte qu'il s'agit d'une véritable poudrière : plus de 33 milliards d'enregistrements seront volés par des cybercriminels rien qu'en 2023, ce qui représente 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 est monté en flèche pour atteindre 4,24 millions de dollars (bien qu'il suffise d'examiner des incidents tels qu'Equifax ou Solar Winds pour constater que la situation peut être bien pire). 

En tant qu'industrie, nous avons longtemps attendu 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 qu'un plus grand nombre de professionnels de la cybersécurité se joignent à nous et nous hissent à un niveau plus élevé de programme de sécurité, mais c'est un fossé que nous n'arrivons pas à combler. Nous attendons la solution miracle qui promet de nous éloigner automatiquement des risques croissants, mais elle n'existe pas et il est très peu probable qu'elle existe. Nous attendons que notre Luke Skywalker nous aide à combattre le côté obscur.

Il s'avère que l'aide (et l'espoir) est en route, sous la forme d'un 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 mûre - et si nos équipes de développement ont le bon niveau de sensibilisation et de compétences en matière de sécurité - 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é lancé par l'Open Source Software Foundation (OpenSSF) et la Linux Foundation, en collaboration avec des responsables de la Maison Blanche, des RSSI de haut niveau et d'autres 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 solide. 

Ce qui est particulièrement intéressant, c'est l'accent mis sur la formation de base et la certification au niveau des développeurs, ainsi que sur les mesures visant à rationaliser les activités internes de nomenclature des logiciels (SBOM). Ces deux éléments sont notoirement difficiles à mettre en œuvre de manière à avoir un impact durable, ce qui peut être attribué en partie à des problèmes de croissance au sein des programmes de sécurité des organisations et à un manque général de maturité en matière de sécurité au sein de la cohorte de développeurs, sans qu'ils en soient responsables. Ils se trouvent dans un environnement sous pression où le volume de code et la vitesse règnent en maîtres, face à des délais de plus en plus déraisonnables. Ajouter encore plus de tâches sous la forme de demandes de sécurité et de maintenance SBOM sans augmenter le temps disponible pour celles-ci est une recette qui a échoué avant même d'avoir commencé, et malheureusement, c'est plus courant que ce que l'on pourrait croire.

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

Certification de sécurité pour les développeurs : En sommes-nous encore là ?

S'il est une chose dont nous sommes sûrs, c'est que les développeurs compétents en matière de sécurité sont encore une denrée rare. C'est la réalité pour un certain nombre de 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. Si l'on ajoute à cela le fait que les développeurs n'ont pas beaucoup de raisons 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 clés de performance et leur principale préoccupation est de faire ce qu'ils font le mieux : créer des fonctionnalités), vous obtenez des équipes de développement qui sont mal préparées pour traiter véritablement la sécurité au niveau du code, ni pour jouer leur rôle dans un cycle de développement logiciel (SDLC) modernisé et centré sur DevSecOps. 

Si nous regardons le plan de mobilisation pour la sécurité des logiciels libres, le tout premier volet du plan en dix points porte sur les compétences des développeurs en matière de sécurité, afin de "fournir à tous une formation et une certification de base en matière de développement de logiciels sécurisés", ce qui est essentiel pour développer la maturité en matière de sécurité au sein des équipes de développement. Il met en évidence 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 de génie logiciel dispensés sur le site courses au niveau tertiaire. Il est incroyablement encourageant de voir que cette initiative est soutenue par des personnes et des départements qui peuvent changer le statu quo de l'industrie, et comme 99 % des logiciels dans le monde contiennent au moins une partie de code source ouvert, ce domaine de développement est un excellent endroit pour commencer à se concentrer sur la formation des développeurs en matière de sécurité.

Le plan cite des ressources vénérées telles que l'OpenSSF Secure Software Fundamentals courses, et les ressources étendues et de longue date de la Fondation OWASP. Ces centres d'information sont inestimables. Le déploiement proposé pour diffuser ces documents en vue d'améliorer les compétences des développeurs implique de réunir un vaste réseau de partenaires, tant dans le secteur public que privé, et de s'associer à des établissements d'enseignement pour faire du développement de logiciels libres sécurisés un élément clé du programme d'études. 

Pour ce qui est de la manière de gagner le cœur et l'esprit des ingénieurs en logiciel du monde entier, dont beaucoup ont vu la sécurité renforcée comme quelque chose qui n'est pas leur travail ou leur priorité, le plan détaille une stratégie de récompense et de reconnaissance pour cibler à 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 en matière 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 n'abordons pas l'un des problèmes fondamentaux, à savoir la fourniture de modules d'apprentissage 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 lorsqu'il s'agit d'outils et de formations, sans parler de tout ce qui semble pouvoir perturber le travail qui est la priorité numéro un. L'habilitation des développeurs exige d'eux qu'ils s'engagent continuellement dans le matériel de cours, et pour que cela réussisse, il faut que cela ait 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), la "formation et l'orientation" est un élément central de la couche Governace, et l'accent est mis sur la formation 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 demandent aux développeurs de suivre une formation formelle à la sécurité plus d'une fois par an. Notre propre étude, menée conjointement avec Evans Data, a révélé que seuls 29 % des développeurs estiment que la pratique active de l'écriture de codes exempts de vulnérabilités devrait être une priorité. Il existe un décalage évident entre la manière dont la formation est dispensée et reçue, et l'utilité réelle de cette formation pour atteindre la maturité en matière de sécurité, en particulier si les développeurs n'en perçoivent pas l'intérêt.

Nomenclature des logiciels : Ce plan permet-il d'éliminer les obstacles à l'adoption ?

Le volet "SBOM Everywhere - Improve SBOM Tooling and Training to Drive Adoption" (SBOM partout - Améliorer les outils et la formation SBOM pour favoriser l'adoption) étudie les moyens de faciliter la création, la mise à jour et l'utilisation des SBOM par les développeurs et leurs organisations afin d'obtenir de meilleurs résultats en matière de sécurité.

À 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 prévoit une stratégie brillante pour définir des normes clés pour la formulation des SBOM, ainsi que des outils pour faciliter la création qui s'adaptent à la façon dont les développeurs travaillent. À eux seuls, ces éléments contribueraient grandement à alléger le fardeau d'une énième tâche du SDLC pour les développeurs qui ont déjà fort à faire pour créer des logiciels à la vitesse de la demande. 

Ce que je crains, cependant, c'est que dans l'organisation moyenne, les responsabilités en matière de sécurité peuvent constituer une véritable zone grise pour les développeurs. Qui est responsable de la sécurité ? En fin de compte, c'est l'équipe de sécurité, mais les développeurs doivent être associés à la démarche si nous voulons qu'ils nous aident. Les tâches et les attentes doivent être clairement définies, et ils ont besoin de temps pour prendre en charge ces mesures supplémentaires de leur succès. 

Des logiciels libres au reste du monde du logiciel

Le plan de mobilisation pour la sécurité des logiciels libres est ambitieux, audacieux et correspond exactement à ce qu'il faut pour responsabiliser les développeurs en matière de sécurité. Il a fallu une "alliance rebelle" de quelques 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 matière de cybersécurité se résorbera de lui-même comme par magie. 

C'est notre nouvel espoir, et il faudra que nous soyons tous capables de 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. assessment Ils doivent faire une évaluation honnête de leurs capacités actuelles, de leurs lacunes et s'efforcer de créer un état final mature, étanche, proactif et comprenant un programme qui transmet de véritables compétences en matière de sécurité à la cohorte de développeurs. Jusqu'à ce qu'ils soient véritablement activés, nous pourrions encore être 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é avec notre défi XSS pratique et interactif !