Si vous demandez, « Qu’est-ce qu’un SBOM? » vous devrez vous rattraper rapidement. Une nomenclature logicielle est la première ligne de défense contre les vulnérabilités logicielles qui peuvent vous guetter, comme des portes déverrouillées dans votre réseau, prêtes à laisser entrer des pirates.

Un SBOM, comme toute nomenclature, répertorie les composants du produit fini, de sorte qu’en cas de problème, les développeurs peuvent se concentrer sur la cause et y remédier avec le moins de perturbations possible. Les SBOM sont la clé de voûte de la sécurité de la chaîne d’approvisionnement, permettant des DevOps plus sécurisés et une meilleure intelligence des menaces pour maintenir des réseaux plus résilients.

Deux ans après qu’un gang de rançongiciels a entravé les livraisons de carburant aux États-Unis en attaquant un exploitant de pipeline, les attaques de la chaîne d’approvisionnement restent un irritant majeur pour les professionnels de la sécurité. À la suite de l’attaque et de la découverte de la vulnérabilité Log4J, les SBOM se sont généralisés alors que les professionnels de la sécurité luttent pour empêcher de futures attaques.

L’ascendance des SBOM et des directives fédérales

Les SBOM ont un moment. Lors de la récente conférence RSA, la Cybersecurity and Infrastructure Security Agency (CISA) du gouvernement fédéral a publié des conseils sur les différents types de SBOM disponibles et leur utilisation.

La CISA a été un promoteur de l’utilisation des SBOM, en particulier depuis le décret exécutif 14028 et la note de service M-22-18 du Bureau de la gestion et du budget qui exigeait l’élaboration d’un formulaire de rapport pour les développeurs de logiciels au service du gouvernement fédéral. CISA organise des réunions SBOM-a-Rama qui rassemblent des types d’industries pour soutenir le développement de CBOM.


Le document CISA est le résultat d’un effort de groupe lancé en 2018 et, comme de nombreux efforts de groupe, il peut devenir difficile à manier. L’intro du document le reconnaît, déclarant : « Compte tenu des manières disparates de collecter les données SBOM, les résultats de l’outil peuvent varier et apporter de la valeur dans différents cas d’utilisation. » Dans cet esprit, il est utile de décomposer les types de SBOM disponibles et certains cas d’utilisation potentiels pour aider à clarifier ceux qui peuvent être les plus utiles pour une organisation.

Décodage des 6 principaux types de SBOM

Il existe six principaux types de SBOM utilisés aujourd’hui au fur et à mesure qu’ils progressent dans les étapes du cycle de vie du développement logiciel :

  • • Conception: Un SBOM de ce type est créé pour un logiciel potentiel ou prévu et comprend des composants qui peuvent ou non exister. Il est généralement développé sur la base d’un appel d’offres, d’un concept ou de spécifications. Bien que théoriquement possible, il est difficile d’imaginer comment cela pourrait aider et comment cela pourrait générer un document lisible par machine qui répondrait aux normes que le gouvernement fédéral soutient.

    Un cas d’utilisation possible pour ce type de SBOM est d’alerter les développeurs des problèmes de licence qui pourraient survenir lors de l’utilisation de certains composants qui affecteraient la propriété intellectuelle ou la distribution du produit fini. Ce SBOM peut aider l’équipe de développement à identifier les éléments incompatibles avant leur achat et à définir une liste de composants approuvés et recommandés. Ce type de SBOM peut également permettre à l’équipe de se procurer les meilleurs composants open source d’un point de vue commercial.

  • • Source: Très similaire au SBOM de type construction, celui-ci est généré dans l’environnement de développement et inclut tous les fichiers source et les dépendances nécessaires pour construire un artefact mais exclut l’outil de construction du processus. Il est généralement produit par l’outil logiciel d’analyse de la composition (SCA), avec quelques clarifications ajoutées manuellement.

    Il est difficile de voir le cas d’utilisation de ce type au lieu du SBOM de type build plus courant. Pourtant, ce SBOM peut repérer les composants vulnérables qui ne sont jamais exécutés après le déploiement, donnant à l’équipe une vue sur l’arborescence des dépendances des composants inclus. Par conséquent, il permet de corriger les vulnérabilités connues à la source dès le début du processus de développement.

    En revanche, il peut manquer certains des détails d’autres types de SBOM, y compris l’exécution, le plug-in ou les composants dynamiques, tels que les bibliothèques de serveurs d’applications.


  • • Construire: Le type de SBOM le plus couramment utilisé, il s’agit d’un inventaire plus complet généré dans le cadre du processus de création du logiciel qui exécutera l’artefact final. Cette approche utilise des données telles que les fichiers source, les dépendances, les composants générés, les données éphémères du processus de génération et les SBOM source et de conception précédents. Il s’appuie sur la résolution de toutes les dépendances dans le système de construction et sur leur analyse sur la machine de construction.

    Étant donné que les fichiers réels sont analysés, ce type de SBOM crée un enregistrement plus complet avec des données riches sur chaque fichier, telles que son hachage et sa source. Offrir plus de visibilité au-delà de ce qui est disponible à partir du code source renforce la confiance que le SBOM représente avec précision le processus de développement. Cette confiance découle de l’intégration du SBOM et du produit fini dans le même flux de travail.

    En revanche, ce SBOM est très dépendant de l’environnement de construction, qui peut parfois devoir changer pour produire le SBOM.

  • • Analysé : Ceci est parfois appelé « SBOM tiers » ou SCA binaire. Il s’appuie sur la numérisation de l’artefact tel qu’il est livré pour déterminer ses composants; et utilise des outils tiers pour analyser des artefacts tels que des packages, des conteneurs et des images de machines virtuelles. Il n’a pas besoin d’accéder à l’environnement de construction et peut revérifier les données SBOM provenant d’autres sources pour trouver les dépendances cachées que les outils de création SBOM ont manquées.

    Puisqu’il effectue essentiellement une ingénierie inverse des composants de l’artefact, il peut être un outil utile pour les consommateurs de logiciels qui ne disposent pas d’un SBOM disponible ou qui peuvent corroborer un SBOM existant.

    En revanche, ce type de SBOM s’appuie souvent sur des heuristiques plus lâches ou des facteurs de risque basés sur le contexte pour tester les composants. Les tests peuvent donc produire des résultats faussement positifs. Mais il est également plus probable de trouver des bibliothèques liées à partir de l’environnement sans que l’équipe de développement ne s’en rende compte, comme OpenSSL libc, ou d’autres qui construisent souvent des SBOM.


  • • Déployé : Comme son nom l’indique, il s’agit d’un inventaire des logiciels déployés dans le système, généralement généré en compilant les SBOM et les informations de configuration des artefacts installés. Il peut combiner l’analyse des options de configuration et l’examen du comportement d’exécution dans un environnement déployé. L’examen des composants logiciels, y compris les autres configurations et les composants système qui exécutent une application, est utile.

    La génération de ce type de SBOM peut nécessiter la modification des processus d’installation et de déploiement, et peut ne pas toujours refléter l’environnement d’exécution de l’artefact, car certains composants peuvent ne pas être accessibles. Mais la large portée de ce type de SBOM en fait une option attrayante.

  • • Durée: Parfois appelé SBOM « instrumenté » ou « dynamique », ce type résout l’angle mort des SBOM déployés. Dans ce cas, les outils interagissent avec le système et enregistrent les artefacts utilisés dans un environnement en cours d’exécution et ceux chargés en mémoire pendant l’exécution. Ce processus aide à éviter les faux positifs provenant de composants inutilisés.

    Ce type de SBOM donne aux développeurs une visibilité sur les composants chargés dynamiquement et les connexions externes et peut leur donner des détails sur les composants actifs et les parties utilisées. Cela ajoute à la surcharge du réseau car le système doit être analysé pendant son exécution. Étant donné qu’il doit fonctionner pendant un certain temps pour utiliser toutes ses fonctionnalités, la collecte d’informations détaillées peut prendre un certain temps.

Réflexions finales sur la sélection des SBOM

Compte tenu de ces détails, la sélection du bon type ou de la bonne combinaison de SBOM pour répondre aux besoins de votre organisation implique plus de considération que le simple choix du premier outil de génération de SBOM disponible à des fins de conformité.

Compte tenu du soutien du gouvernement fédéral, le SBOM est sans aucun doute là pour rester, et il peut établir une base solide, introduisant de l’ordre dans le processus parfois chaotique de sécurisation des produits logiciels.

A lire également