Aller au contenu
FortaRisks
Retour au glossaireRisque tiers et chaîne d'approvisionnement

SBOM (nomenclature logicielle)

Un SBOM (Software Bill of Materials) est l'inventaire complet et structuré des composants, bibliothèques et dépendances qui constituent un logiciel. Il fonctionne comme une liste d'ingrédients : sans lui, une organisation ne peut pas savoir rapidement si un composant vulnérable se cache dans ce qu'elle utilise.

Mis à jour le 2 juillet 2026

Qu'est-ce qu'un SBOM ?

Un SBOM, ou nomenclature logicielle (Software Bill of Materials), est un inventaire formel de tous les composants qui entrent dans la composition d'une application : bibliothèques open source, modules tiers, dépendances transitives et versions associées. Par analogie, c'est la liste des ingrédients d'un produit alimentaire, transposée au logiciel.

Les logiciels modernes sont assemblés bien plus qu'ils ne sont écrits : une application typique repose sur des centaines de composants tiers, dont la plupart proviennent de projets open source maintenus par des équipes que vous ne contrôlez pas.

Pourquoi c'est important pour votre organisation

Sans SBOM, vous ne pouvez pas répondre rapidement à la question la plus urgente en cas de faille : « ce composant vulnérable est-il présent chez nous, et où ? ». Les incidents comme Log4Shell ont montré que les organisations dotées d'un SBOM à jour ont réagi en heures, tandis que les autres ont passé des jours à chercher à l'aveugle.

Le SBOM est aussi un pilier de la gestion du risque tiers : il rend visible la chaîne d'approvisionnement logicielle, souvent le point aveugle des questionnaires fournisseurs. Il devient progressivement une exigence réglementaire et contractuelle, notamment dans les marchés publics et les secteurs critiques.

Ce qu'un bon SBOM doit contenir

  • Nom et version de chaque composant.
  • Fournisseur ou origine du composant.
  • Identifiants uniques (par exemple Package URL ou CPE) pour la corrélation automatisée.
  • Relations de dépendance entre composants, y compris les dépendances transitives.
  • Informations de licence, utiles au risque juridique autant qu'au risque de sécurité.

Où les organisations pèchent le plus souvent

Générer un SBOM une fois ne suffit pas : il doit être régénéré à chaque version et confronté en continu aux bases de vulnérabilités. Beaucoup d'organisations produisent un SBOM pour cocher une case, sans l'intégrer à leur processus de gestion des correctifs ni exiger de SBOM de leurs propres fournisseurs. Un SBOM statique et isolé perd l'essentiel de sa valeur.

Questions fréquentes

À quoi sert concrètement un SBOM ?

Quand une vulnérabilité critique est publiée dans une bibliothèque très répandue, un SBOM permet de répondre en minutes à la question « sommes-nous exposés et où ? ». Sans SBOM, cette réponse demande des jours d'enquête manuelle, temps pendant lequel les attaquants agissent.

Quels sont les formats de SBOM les plus courants ?

Les deux standards les plus répandus sont SPDX, porté par la Linux Foundation, et CycloneDX, porté par l'OWASP. Les deux sont lisibles par machine, ce qui permet d'automatiser la corrélation entre vos composants et les bases de vulnérabilités.

Voyez votre vrai risque en 30 minutes de démo.

Un membre de notre équipe vous guide dans FortaRisks sur des menaces pertinentes pour votre secteur. Sans chatbot.