Cybersécurité : le CNCF et la CISA se penchent sur l’adaptation du SBOM au cloud
Les discussions dans l’industrie sur la manière de surmonter les problèmes de sécurité du cloud à l’aide des SBOM incluent une initiative récente de la CNCF qui exploite une base de données orientée graphes pour gérer les métadonnées transitoires.
Bien que populaire, l’émergence d’une nomenclature logicielle (Software Bill Of Materials ou SBOM en VO) consacrée à la sécurité du cloud computing a été entravée par des problèmes techniques non résolus.
Un SBOM fournit une liste lisible par machine des composants sous-jacents et des dépendances d’une application. Il s’est imposé comme un élément clé de la sécurité de la chaîne d’approvisionnement logicielle. Depuis l’attaque de SolarWinds et la vulnérabilité critique de Log4j, la supply chain logicielle fait l’objet de l’attention du secteur. Il est fort probable que des listes exhaustives de composants logiciels auraient aidé les professionnels de l’IT à atténuer plus rapidement les problèmes de sécurité.
Le SBOM figurait également parmi les outils de sécurisation des chaînes d’approvisionnement logicielles mentionnés dans le décret 14028, promulgué par l’administration Biden en mai 2021. Cet « Executive Order » impose une nouvelle base de normes de sécurité logicielle utilisées par le gouvernement fédéral. Ce décret réclame aux agences, telles que la National Telecommunications and Information Administration (NTIA), de publier les « éléments minimums » de leur SBOM. Il exige par ailleurs que les agences fédérales demandent aux éditeurs de logiciels et de services de se conformer à la définition de la NTIA.
Toutefois, dans sa version initiale, la définition de la NTIA se concentre spécifiquement sur les déploiements de logiciels sur site et décrit les problèmes non résolus liés à l’utilisation du SBOM en mode cloud et SaaS.
C’est plus particulièrement le modèle de responsabilité partagée qui soulève une question. Avec ce modèle, le fournisseur d’un cloud ou d’un service SaaS assume la responsabilité de l’infrastructure de bas niveau et des composants des systèmes d’exploitation. Le client, lui endosse la responsabilité des frameworks et des applications de plus haut niveau. Cependant, le client et le fournisseur ne disposent pas d’informations détaillées sur les composants logiciels et les dépendances de chacun, ce qui rend difficile l’établissement d’un SBOM couvrant l’ensemble de l’environnement.
L’utilisation du SBOM pour la sécurité du cloud est d’autant plus compliquée que même si est facile de générer un inventaire complet pour un environnement cloud, il ne serait précis que pour une période limitée. En effet, les ressources cloud sont par nature éphémères.
« La collecte significative de métadonnées sur l’ensemble de la pile applicative et des services tiers est un travail en cours, mais il n’est pas encore normalisé ou suffisamment mature pour être mis en œuvre par plusieurs organisations », selon la NTIA.
Pourtant, il est clair que le SBOM est en passe de devenir un élément clé de la sécurité du cloud, au sein des instances du gouvernement américain, et en dehors. Un rapport publié en février par la Fondation Linux sur le SBOM et la préparation à la cybersécurité indique que sur 412 organisations interrogées, 47 % produisent ou consomment des SBOM. De plus, l’utilisation de SBOM devrait augmenter de 66 % en 2022 et 88 % des organisations utiliseront un tel inventaire en 2023.
« Des solutions émergent, mais le consensus des experts de l’industrie doit encore se consolider autour d’une méthodologie, d’un format et d’un flux d’outils particuliers ».
Fondation LinuxRapport sur l'état du SBOM
« Des solutions émergent, mais le consensus des experts de l’industrie doit encore se consolider autour d’une méthodologie, d’un format et d’un flux d’outils particuliers », ajoute le rapport. « Un soutien très visible de la part de la communauté des fournisseurs de logiciels et de services servirait d’accélérateur clé et validerait le rôle des SBOM dans la sécurisation de la chaîne logistique logicielle. »
SBOM : la CISA pointe le manque de cohésion du secteur
Les jeunes éditeurs spécialisés dans la sécurité du cloud, tels que Rezilion et Anchore (un sous-traitant du Département de la Défense), affirment déjà offrir un SBOM capable de suivre l’évolution rapide des infrastructures de cloud et des conteneurs. Les outils de ces éditeurs indiquent également quels composants logiciels du SBOM dynamique sont réellement utilisés dans un environnement. Cela doit aider les opérateurs à établir des priorités en matière de réduction des vulnérabilités.
Toutefois, selon les observateurs du secteur, il faudra un effort plus important de la part des organisations pour répondre à l’ensemble des exigences du SBOM en matière de sécurité du cloud.
Rezilion, un éditeur d’une solution de gestion des vulnérabilités, se concentre sur la remédiation ainsi que sur la création de SBOM ; il offre gratuitement ses outils de visibilité des composants logiciels. Il reste cependant beaucoup de place pour la consolidation des approches et des normes, en particulier les standards qui couvrent les environnements sur site, en cloud public, mobiles et SaaS, selon Liran Tancman, PDG de Rezilion.
Les responsables de l’Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA) et de la Cloud Native Computing Foundation (CNCF) sont du même avis. À la mi-juillet 2022, la CISA a conclu une série d’auditions sur les problèmes actuels du SBOM. Deux d’entre elles sont consacrées spécifiquement aux défis de la sécurité du cloud.
La CISA n’a pas l’intention d’utiliser ces sessions pour informer la politique du gouvernement fédéral américain. Elle cherche plutôt à encourager un débat élargi au sein de l'industrie concernant des moyens standard de résoudre ces problèmes, selon Allan Friedman, conseiller principal et stratège à la CISA. Allan Friedman a conduit les auditions menées en juillet dernier.
« Le défi consistera à réduire l’éventail des activités possibles afin que le SBOM puisse s’adapter à la flexibilité exigée par les différentes organisations et les différents types de technologies, sans qu’il y ait un milliard de solutions différentes en circulation », résume-t-il dans un entretien.
Certains participants à ces discussions, issues d’organisations diverses telles que des agences gouvernementales, des communautés open source cpùùe la CNCF et les fournisseurs cloud Microsoft et Google, ont suggéré qu’en l’absence de standards pour l’établissement d’un SBOM consacré au cloud, les organisations devraient plutôt se concentrer sur les moyens de vérifier rapidement si leurs applications cloud sont vulnérables. À cet effet, le Vulnerability Exploitability eXchange (VEX), un format lisible par machine pour les avis de sécurité, permet d’identifier exactement les vulnérabilités de sécurité qui sont pertinentes dans les environnements cloud à un moment donné.
« À court terme [certaines organisations] sont beaucoup plus intéressées par les attestations », affirme Allan Friedman. « Je ne dis pas que c’est ce que nous nous attendons à voir dans le domaine du cloud, mais nous sommes très sensibles à l’idée que les différentes parties de l’écosystème vont évoluer à des rythmes différents et recherchent différents éléments. »
Une base de données orientée graphes pour propulser un SBOM
Les membres du groupe consultatif technique sur la sécurité (STAG) de la CNCF travaillent à l’élaboration de directives pour le SBOM natif du cloud. Le groupe a également accueilli en juillet une présentation de Palo Alto Networks sur les nomenclatures d’infrastructure. Ce concept permettrait d’intégrer les données de configuration des outils d’infrastructure-as-code dans la liste des composants de SBOM afin d’offrir une image ponctuelle plus claire des environnements cloud-native.
Un autre effort très précoce au sein de la CNCF – encore sans nom et non documenté, mais référencé par les responsables du STAG de la CNCF lors des sessions d’écoute de la CISA – utiliserait une base de données orientée graphes pour suivre les relations entre les composants de métadonnées du SBOM. Cela créerait ainsi un inventaire interrogeable et modulable qui peut s’adapter aux ressources éphémères du cloud dans plusieurs environnements.
« Le processus de réflexion est le suivant : pouvons-nous ingérer toutes ces métadonnées qui sortent, autour de la provenance [du code] et des SBOM, et les placer dans une base de données orientée graphes qui serait interrogeable à l’avenir ? », explique Parth Patel, COO et cofondateur de la startup Kusari, spécialisée dans la sécurité de la chaîne d’approvisionnement logicielle. Il est également membre du STAG de la CNCF et participe aux premières discussions sur l’idée du projet de base de données orientée graphes.
Le STAG travaillera également à la normalisation des champs de données qui doivent être inclus dans le SBOM spécifique au cloud, afin de pouvoir alimenter une telle base de données de manière cohérente, selon Parth Patel.
« Il s’agit de s’assurer que même si elles sont dans des formats différents, tant que les informations sont là, nous pouvons tout de même les interroger ».
Parth PatelCOO et cofondateur, Kusari
« Il s’agit de s’assurer que même si elles sont dans des formats différents, tant que les informations sont là, nous pouvons tout de même les interroger », avance-t-il.
Parth Patel indique que le groupe CNCF travaillant sur le projet de base de données prépare une présentation plus détaillée pour le KubeCon North America en octobre.
« Comment savoir quand le SBOM n’est plus à jour ? C’est notre question », poursuit-il. « Nous allons continuellement tirer des informations de toutes les différentes sources de données qui sont disponibles… donc si elle n’est pas valide ou périmée, nous le gérerions. »
Garder la trace des métadonnées qui changent rapidement n’est cependant qu’une petite pièce du puzzle du SBOM pour le cloud. Les moyens de partager et d’échanger des informations SBOM entre les organisations ont fait l’objet de leur propre série de sessions d’écoute de la CISA. Les interrogations allaient de la manière de fournir aux clients des données SBOM sans révéler d’informations potentiellement sensibles ou propriétaires par l’utilisation de contrôles d’accès à la nécessité de conventions de dénomination standardisées pour les ressources dans les différents environnements.
« Assembler tous ces éléments n’est pas aussi simple que de le dire », admet Allen Friedman. « Mais nous avons vu des progrès incroyables au cours des 12 derniers mois, et je ne vois pas pourquoi ce rythme devrait ralentir. »
