SBOM : Comprendre la " liste d'ingrédients " des logiciels pour une sécurité optimale

SBOM (Software Bill of Materials) est devenu un outil essentiel pour la sécurité logicielle. À l'ère des logiciels modernes, rares sont les programmes écrits entièrement de zéro : chaque application intègre souvent des dizaines, voire des centaines de bibliothèques tierces, de frameworks et de modules. Chacun accélère le développement, mais devient aussi un maillon de la chaîne de sécurité globale.

Qu'est-ce qu'un SBOM et pourquoi parle-t-on de " liste d'ingrédients " ?

Un SBOM est une liste structurée et détaillée de tous les composants d'un logiciel, précisant leurs versions et relations. À l'image de la liste d'ingrédients affichée sur l'emballage d'un aliment, le SBOM permet de savoir précisément ce qui compose un programme. Si une vulnérabilité est découverte dans une bibliothèque, ce document permet d'identifier rapidement si celle-ci est utilisée dans une application et quels produits nécessitent une vérification ou une mise à jour.

Pourquoi la comparaison avec la liste d'ingrédients ?

Le principe est simple : tout comme un consommateur peut vérifier la composition d'un produit alimentaire, le SBOM dévoile toutes les bibliothèques, packages et modules utilisés pour construire l'application. Cela est crucial, car la majorité des logiciels actuels repose sur du code externe. Un développeur peut écrire la logique principale, mais s'appuyer sur des bibliothèques prêtes à l'emploi pour la gestion réseau, le chiffrement, les bases de données ou l'interface utilisateur.

Définition du Software Bill of Materials

Le terme Bill of Materials (BOM) vient de l'industrie : il désigne l'inventaire de toutes les pièces nécessaires à l'assemblage d'un produit, par exemple une voiture. Le SBOM transpose ce concept à l'informatique : au lieu de boulons et de puces, il s'agit de bibliothèques logicielles, dépendances et packages.

Par exemple, un service web peut utiliser un framework, une bibliothèque de chiffrement, un pilote de base de données et des dizaines d'autres packages, eux-mêmes dépendants d'autres bibliothèques. Résultat : la structure réelle du projet est bien plus complexe qu'il n'y paraît au premier abord. Le SBOM rend cette structure transparente.

Que contient un SBOM ?

Le contenu exact dépend du format et des outils employés, mais généralement, un SBOM inclut les informations suivantes pour chaque composant :

• Nom de la bibliothèque ou du package ;
• Version du composant ;
• Éditeur ou fournisseur ;
• Identifiants uniques du package ;
• Licence ;
• Liens avec d'autres dépendances ;
• Origine du composant.

La version est particulièrement importante : une même bibliothèque peut avoir une version vulnérable et une autre corrigée. Seul le nom ne suffit pas, il est essentiel d'identifier précisément la version utilisée.

Les relations entre dépendances sont aussi essentielles. Une application peut indirectement intégrer une bibliothèque vulnérable via la chaîne de dépendances, phénomène appelé dépendances transitives.

Exemple : l'application utilise la bibliothèque A, qui dépend de B, elle-même dépendante de C. Le code de C se retrouve ainsi dans le produit final, même si le développeur ne l'a jamais ajoutée explicitement.

SBOM vs liste de dépendances classique

Un SBOM ressemble à première vue à un fichier de dépendances (comme package.json pour JavaScript ou requirements.txt pour Python). Mais un fichier de dépendances sert principalement au système de build ou au gestionnaire de packages pour installer les modules nécessaires à l'exécution du projet.

Le SBOM, lui, est un document standardisé, lisible par machine, destiné à la cybersécurité, à l'analyse de la supply chain logicielle et aux plateformes de veille sur les vulnérabilités. Il décrit la structure réelle du logiciel, y compris les dépendances profondes, et peut être analysé automatiquement à l'apparition de nouvelles menaces.

Pourquoi le SBOM facilite la détection des vulnérabilités ?

L'un des principaux avantages du SBOM est d'identifier rapidement si une nouvelle vulnérabilité affecte un logiciel donné. Sans SBOM, les équipes doivent vérifier manuellement chaque projet - une tâche titanesque pour les grandes infrastructures.

Le risque est particulièrement élevé lorsque de nombreuses bibliothèques open source sont utilisées. Une faille peut se cacher dans une dépendance obscure, connue seulement d'une partie de l'équipe. Le SBOM rend ces composants visibles.

L'effet domino des vulnérabilités

Les bibliothèques populaires sont utilisées par des milliers de projets. Une faille dans une seule composante peut donc impacter une multitude d'applications, de serveurs et de services.

Imaginons qu'une bibliothèque en version 3.4 soit utilisée ; une faille est découverte, corrigée en 3.4.1. Une entreprise qui connaît précisément la composition de ses produits pourra rapidement localiser les versions à mettre à jour.

Sans SBOM, il faut fouiller les dépôts, les fichiers de dépendances, les images de conteneurs, etc. Les dépendances transitives compliquent encore la tâche : une bibliothèque apparemment sûre peut inclure une autre vulnérable.

Un problème similaire se pose avec les vulnérabilités zero-day, où la rapidité d'identification des systèmes concernés est cruciale après la publication d'une menace.

Comment le SBOM accélère la réaction après la découverte d'une faille

Lorsqu'une nouvelle vulnérabilité est annoncée, les experts doivent déterminer si le composant en question est utilisé, dans quels produits et en quelle version. Un SBOM à jour permet d'automatiser cette vérification : il suffit de chercher le nom et la version du composant pour dresser la liste des applications potentiellement exposées.

C'est particulièrement utile dans les grandes entreprises, où des centaines de services coexistent. Plutôt que de solliciter chaque équipe, l'organisation dispose d'un mécanisme centralisé pour repérer les dépendances à risque.

Attention : la présence d'un composant ne signifie pas toujours que l'application est vulnérable. Il peut arriver que la fonction à risque ne soit jamais appelée. Le SBOM délimite donc la zone à surveiller, mais une évaluation de risque complémentaire peut s'avérer nécessaire.

SBOM et analyse des dépendances vulnérables

Le SBOM prend tout son sens associé à des bases de vulnérabilités connues et à des scanners de sécurité automatisés. Le principe : la liste des composants et leurs versions est confrontée à la base des failles connues. Si un problème est référencé pour une version donnée, le projet est signalé pour contrôle.

Cette démarche permet de réanalyser périodiquement les logiciels déjà déployés, car un composant jugé sûr lors de la sortie peut s'avérer vulnérable des mois plus tard. La composition du logiciel change peu, mais l'information sur la sécurité des éléments évolue sans cesse.

Le SBOM sert ici d'inventaire précis : il répond à la question " qu'y a-t-il dans le programme ? ", tandis que les outils d'analyse détectent les composants à surveiller.

Le SBOM en pratique

En pratique, le SBOM est généralement généré automatiquement lors du développement, de la compilation ou de la publication d'un logiciel. Des outils analysent le projet, identifient les composants et créent un fichier structuré.

L'intérêt principal : le SBOM s'intègre au cycle de vie normal du logiciel et se met à jour à chaque nouvelle release.

Génération du SBOM pendant le développement

Le SBOM peut être produit à différents stades : un outil analyse les fichiers de dépendances, un autre examine le conteneur compilé, un troisième interroge directement le système de build. Lorsqu'une nouvelle bibliothèque est ajoutée, le système la détecte à la compilation suivante et l'ajoute au SBOM.

Ce processus s'intègre parfaitement aux chaînes CI/CD modernes : la génération du SBOM accompagne les tests, la compilation et les contrôles de sécurité. Ainsi, l'automatisation des processus de développement peut inclure la génération et la vérification systématique du SBOM.

Un SBOM distinct peut être conservé pour chaque version, permettant de retracer la composition exacte d'une release même longtemps après sa sortie.

Contrôle des composants et de leurs versions

Après génération, le SBOM peut être transmis à un système d'analyse de vulnérabilités : celui-ci extrait les noms, versions et identifiants, puis les compare à une base de failles connues.

La qualité de la vérification dépend de la précision des données. Si la version d'un composant est mal renseignée ou ambiguë, le rapprochement avec les bases de vulnérabilités perd en fiabilité. Un bon SBOM doit donc fournir des informations complètes pour permettre une identification sans équivoque.

Que faire en cas de dépendance vulnérable ?

Lorsqu'un composant à risque est détecté, la première étape consiste à mesurer l'ampleur du problème : quels produits et versions sont concernés ? Ensuite, il faut évaluer le risque réel : la simple présence d'une bibliothèque impose parfois une mise à jour urgente, mais il arrive que la fonction vulnérable ne soit jamais utilisée, limitant le danger immédiat.

Si une version corrigée existe, on met à jour la dépendance, on recompile et on régénère le SBOM. En l'absence de correctif, on peut désactiver une fonction, modifier la configuration ou recourir à une alternative pour limiter le risque.

Le SBOM aide donc à localiser rapidement les zones à corriger et à prioriser les actions.

Pourquoi maintenir le SBOM à jour ?

Le SBOM n'est utile que s'il reflète l'état réel du logiciel. Un SBOM daté d'un an et non mis à jour après des changements de dépendances devient dangereux à utiliser.

Il faut donc considérer le SBOM comme un élément vivant, évoluant à chaque version du logiciel. Toute modification - ajout, mise à jour ou suppression de composant - doit être reflétée dans le SBOM, créant ainsi une véritable histoire de la composition du produit.

Les formats SBOM : CycloneDX et SPDX

Le SBOM n'est pas un format unique. Pour permettre l'interopérabilité entre outils, plusieurs standards existent, parmi lesquels CycloneDX et SPDX sont les plus répandus.

CycloneDX

CycloneDX a été conçu avec un fort accent sur la sécurité de la chaîne d'approvisionnement logicielle. Ce format décrit les bibliothèques, packages, services et leurs relations, et peut intégrer identifiants, licences, empreintes de fichiers, etc. Il facilite ainsi la détection automatique des failles via des systèmes de sécurité, et sa carte des dépendances met en valeur la structure réelle de l'application.

SPDX

SPDX (Software Package Data Exchange) est largement utilisé pour documenter les packages, leur origine et leur licence. Il s'adapte aussi bien à l'analyse de la sécurité qu'au contrôle de l'usage du code open source, notamment dans les grands projets intégrant de nombreux composants tiers.

SPDX et CycloneDX peuvent être convertis l'un en l'autre selon les besoins des outils utilisés.

Le choix du format

Dans bon nombre de projets, le format du SBOM est imposé par les outils ou les exigences du client. L'important est que le SBOM soit complet : il doit lister toutes les dépendances, directes et transitives, avec des informations à jour et précises.

Des conversions entre formats sont possibles si plusieurs systèmes l'exigent : l'essentiel est la compatibilité et la mise à jour permanente du SBOM.

Le SBOM : un outil, pas une garantie de sécurité

Un SBOM apporte de la transparence, mais n'assure pas à lui seul la sécurité. Il fournit une carte détaillée des composants ; il appartient ensuite à l'équipe de sécurité de croiser ces données avec les bases de vulnérabilités, d'évaluer le risque, de mettre à jour les dépendances et de contrôler chaque nouvelle version.

Limites et risques d'un SBOM obsolète ou incomplet

Un SBOM inexact fausse l'analyse : si des dépendances transitives ne sont pas listées, une bibliothèque vulnérable peut passer inaperçue. À l'inverse, si un composant a été mis à jour mais que le SBOM n'a pas suivi, le projet peut être faussement considéré à risque.

La génération du SBOM doit donc être automatisée et liée à chaque build pour limiter les erreurs humaines et garantir l'actualité des informations.

Certains composants sont parfois difficiles à identifier (versions modifiées, paquets internes), ce qui complique leur rapprochement avec les bases de vulnérabilités externes.

SBOM et sécurité de la chaîne d'approvisionnement logicielle

La sécurité d'une application dépend aussi de ses dépendances, conteneurs, systèmes de build et outils de développement. L'ensemble forme une chaîne d'approvisionnement logicielle, où la compromission d'un seul élément peut avoir des conséquences en cascade.

C'est pourquoi la cybersécurité de demain inclut le contrôle permanent des composants tiers, la vérification de leur origine, de leurs signatures numériques, la mise à jour régulière des bibliothèques et l'analyse continue des vulnérabilités.

Le SBOM permet de savoir précisément quels composants sont utilisés et où. Sans cet inventaire, la réponse à une faille devient une enquête fastidieuse ; avec un SBOM à jour, la zone à examiner est réduite, ce qui accélère la réaction et la résolution du problème.

FAQ

1. Qu'est-ce qu'un SBOM en termes simples ?

   Un SBOM est une liste structurée de tous les composants d'un programme : bibliothèques, packages, leurs versions et les relations entre dépendances. Il permet de comprendre la composition réelle d'une application et de repérer plus rapidement les éléments potentiellement vulnérables.

2. Pourquoi une application standard aurait-elle besoin d'un SBOM ?

   Même un petit programme peut intégrer de nombreuses bibliothèques tierces. Si l'une d'elles est touchée par une faille, le SBOM permet de vérifier rapidement sa présence et la version utilisée dans le produit. C'est particulièrement utile pour les projets maintenus sur la durée, car des failles apparaissent régulièrement dans des dépendances anciennes.

3. Le SBOM peut-il trouver automatiquement une vulnérabilité ?

   Le SBOM ne détecte pas lui-même les failles. Il décrit la composition du logiciel. Pour repérer les problèmes, on l'utilise avec des scanners et des bases de vulnérabilités : le système compare les composants du SBOM avec les menaces connues et signale les éventuelles correspondances. Les développeurs doivent ensuite évaluer le risque réel et corriger si besoin.

4. Quelle différence entre CycloneDX et SPDX ?

   CycloneDX et SPDX sont deux formats majeurs pour décrire un SBOM. CycloneDX est très utilisé pour la sécurité de la chaîne d'approvisionnement et met l'accent sur les relations entre composants, tandis que SPDX se concentre aussi sur l'origine et la licence des packages. Ce qui compte avant tout, c'est la complétude et l'actualité des données du SBOM.

Conclusion

Le SBOM s'apparente à la " liste d'ingrédients " d'un logiciel : il recense toutes les bibliothèques, packages et composants, ainsi que leurs versions et liens de dépendance. Sa principale utilité se révèle lorsqu'une faille est découverte : au lieu d'inspecter manuellement chaque projet, l'entreprise peut s'appuyer sur le SBOM pour identifier rapidement les produits à risque, ce qui est essentiel dans les environnements modernes fortement dépendants du code tiers et des dépendances transitives.

Mais le SBOM ne remplace pas une politique de cybersécurité complète : il ne corrige pas les failles ni ne garantit la sécurité. Sa valeur est dans la transparence : il fournit une cartographie précise, exploitable automatiquement face à de nouvelles menaces. Pour qu'il soit efficace, il doit être généré à chaque version et mis à jour à chaque changement de dépendance. Couplé à des scanners et à des mises à jour régulières, il simplifie considérablement la gestion de la sécurité logicielle.