Il y a un grand mouvement en cours pour passer à un monde orienté SBOM. Si cet acronyme ne vous dit rien, sachez qu’un SBOM est un « Software Bill of Materials » ou nomenclature des logiciels. Le concept est que tout logiciel ou service informatique devrait être accompagné de l’équivalent d’une étiquette des composants, énumérant tous les modules logiciels inclus dans la fabrication du produit final. De cette façon, toute vulnérabilité dans un composant qui n’est pas corrigé devient visible pour les clients. Voilà une idée qui semble toute simple :il suffit juste de lister les logiciels utilisés pour assembler le système !
Juste.
C’est le mot le plus dangereux en matière de cybersécurité. Dans tout système complexe, on est tenté d’utiliser un modèle très simplifié pour le décrire. Souvent, cela peut être utile, car cela rend le système plus facile à appréhender. Malheureusement, les solutions qui s’appliquent aux systèmes simples ne sont généralement pas aussi faciles, et rarement aussi efficaces, dans les systèmes plus complexes.
Les logiciels ne sont pas un paquet de gâteaux
Le modèle de l’étiquetage des ingrédients alimentaires est souvent utilisé pour justifier la publication des SBOM. Mais même si la chaîne d’approvisionnement alimentaire est compliquée, la chimie sous-tend la liste des ingrédients. Même si les sucres sont complexes (dextrose, saccharose, etc.), il n’y a en fin de compte qu’une poignée de façons d’inclure du sucre (ou des édulcorants).Les composants logiciels, au contraire, évoluent en permanence. Imaginez que vous achetiez un aliment et que l’étiquette des ingrédients contienne « gnusugar-12.17.64-bigpharma-5.2.4.a. ».Et demain, cela pourrait changer en « gnusugar-12.17.66-bigpharma-5.2.4.b ». Pour certaines personnes, cela peut s’avérer utile, mais c’est un niveau de complexité qui est supprimé de la chaîne d’approvisionnement alimentaire. Une liste d’ingrédients n’a pas besoin de contenir la provenance spécifique de chaque ingrédient, alors que pour les SBOM, la provenance est une information clé.
Mais en fait : les logiciels sont comme des plats cuisinés
L’ingrédient que je préfère lorsque j’achète de la nourriture est celui des « épices » (ou, arômes artificiels et naturels). Après la vérification des allergènes, c’est l’ingrédient le plus important auquel je fais attention (à quel point est-ce épicé exactement ?), et pourtant c’est un ingrédient où il n’y a aucune transparence. Les SBOM présentent eux aussi un défaut intrinsèque qui permet de se soustraire à la transparence : les logiciels développés en interne. Le logiciel qu’une entreprise inclut de tierces parties doit apparaître dans les SBOM, d’une manière qui, aussi obscure que puisse être la formulation, reste toujours déchiffrable. Mais le logiciel qu’une entreprise écrit elle-même ? Puisqu’il est propriétaire, il s’agit essentiellement « d’épices ».
En quoi cela est-il important ? Par exemple, un développeur de logiciels, qui veut utiliser un logiciel libre dans son composant. Mais, s’il le fait, il devra garder la trace de ce sous-composant pour toujours, et gérer les demandes internes et externes pour savoir pourquoi il ne l’a pas récemment mis à jour. Si, au contraire, ils écrivent leur propre version, même si elle ne fonctionne pas aussi bien, pas besoin de l’inscrire dans le SBOM ! Quelle est la probabilité qu’un ingénieur fasse ce choix ?
Les services logiciels sont comme des restaurants
L’achat d’un service logiciel n’est pas du tout comme l’achat d’un paquet de gâteau ; vous utilisez un service. Ce service fait partie de la chaîne d’approvisionnement intégrée d’un certain nombre de produits logiciels, et chacun d’entre eux est couvert par un SBOM. Imaginez une liste d’ingrédients alimentaires qui n’inclurait pas seulement les produits chimiques contenus dans les aliments, mais aussi tous les équipements de la cuisine, tous les vêtements portés par les cuisiniers, ainsi que les produits d’hygiène personnelle utilisés par chacun d’entre eux. Et cela concerne aussi la chaîne d’approvisionnement du restaurant. Chacun de ses fournisseurs, des chaînes d’approvisionnement aux exploitations agricoles, devra fournir ces mêmes informations au restaurant pour qu’il les fournir aux clients. On obtient une liste énorme, souvent sans contexte pour le consommateur.
Mais un consommateur avec une liste aussi longue devient un coût pour les entreprises. Plus la liste d’informations exposées, même à des clients légitimes, est importante, plus le coût probable pour répondre aux questions à propos de cette liste est élevé. Chaque client peut avoir un domaine de passion ou d’expertise spécifique, et dans ce domaine, il se sentira à l’aise pour contester les choix commerciaux faits par le fournisseur, surtout si ces choix lui sont exposés. Certaines de ces questions peuvent être bien intentionnées (« pourquoi cette version obsolète d’Open SSL quelque part dans votre chaîne d’approvisionnement ? »), mais d’autres peuvent simplement être des questions mesquines (« je travaille sur le composant X, pourquoi avez-vous utilisé le composant concurrent Y dans votre logiciel ? »).Et certaines demandes de renseignements pourront créer une confusion. Les produits de nettoyage sont toxiques dans votre nourriture, mais tout à fait sûrs s’ils sont utilisés uniquement pour nettoyer le sol de la cuisine. Mais comment un consommateur peut-il déterminer cela à partir d’une simple liste?
Les SBOM sont-ils si terribles ?
Pas du tout !Mais la valeur marginale d’un SBOM visible de l’extérieur est, au mieux ,négligeable, et, au pire, négative. Et un SBOM interne ?Il a, lui, une valeur considérable.
Chaque pièce de logiciel qu’une entreprise utilise devrait être connue de cette entreprise. Il faut être en mesure d’identifier chaque sous-composant et de comprendre quelles vulnérabilités peuvent y être présentes, et dans quelle mesure elles sont pertinentes pour l’utilisation de cet élément par l’entreprise. Il faut également savoir dans quelle mesure les équipes d’ingénieurs sont à l’affût des logiciels problématiques et si elles donnent la priorité aux corrections en fonction de la tolérance au risque de l’entreprise.
Finalement, faut-il publier ces données détaillées ?Cela coûtera cher, tant en production qu’en entretien des relations avec les clients, et n’apportera pas un avantage magique pour sécuriser la chaîne d’approvisionnement des logiciels.
Par Andy Ellis, Advisory CISO chez Orca Security
