Qu'est-ce qu'un SBOM ? Définition, formats et mise en place en PME
Par l'équipe Lysbor · publié le · 5 min de lecture
Un SBOM (Software Bill of Materials, ou nomenclature logicielle) est la liste de tous les composants qui entrent dans un logiciel : bibliothèques open source, paquets, frameworks, paquets système d'une image Docker, chacun avec sa version exacte. C'est l'étiquette des ingrédients de votre application.
Quand un fabricant rappelle un lot de farine contaminée, le boulanger qui tient la liste de ses ingrédients sait en cinq minutes s'il est concerné. Celui qui ne la tient pas doit vider ses placards. Le SBOM, c'est la liste du boulanger, et une CVE, c'est le rappel du lot.
Pourquoi c'est devenu incontournable
Une application web moderne embarque couramment plusieurs centaines de dépendances, dont la grande majorité sont transitives : vous installez un paquet, qui en installe dix autres, qui en installent chacun cinq. Personne dans l'équipe ne les a choisies une par une, et pourtant elles tournent en production.
Chaque jour, de nouvelles vulnérabilités sont publiées sur ces composants. Sans inventaire, la question « sommes-nous touchés ? » demande de fouiller chaque dépôt à la main. Avec un SBOM à jour, elle se règle par une simple comparaison.
Trois forces poussent aujourd'hui les PME à en produire un :
- Les clients : les grands comptes et les acheteurs publics demandent de plus en plus la liste des composants et la preuve de leur suivi dans leurs questionnaires de sécurité.
- La réglementation : le Cyber Resilience Act exige un SBOM pour les produits comportant des éléments numériques vendus dans l'Union européenne, et NIS2 demande de maîtriser la sécurité de la chaîne d'approvisionnement.
- Les attaques : les incidents comme Log4Shell (fin 2021) ou les paquets malveillants publiés sur npm et PyPI ont montré que le risque vient souvent d'un composant que personne ne savait présent.
Ce que contient un SBOM
Un SBOM utile décrit, pour chaque composant :
- son nom et sa version exacte ;
- son identifiant standard, le plus souvent un purl (package URL), par exemple
pkg:npm/lodash@4.17.21, qui permet de le retrouver sans ambiguïté dans les bases de vulnérabilités ; - sa licence (MIT, Apache 2.0, GPL…), utile pour la conformité juridique ;
- ses relations : quel composant dépend de quel autre ;
- parfois une empreinte (hash) pour vérifier son intégrité.
Le SBOM ne contient ni votre code source ni vos secrets. C'est un document descriptif, que l'on peut partager avec un client ou un auditeur sans exposer la propriété intellectuelle.
Les deux formats standards
Deux formats ouverts dominent, et les outils sérieux savent lire les deux :
| CycloneDX | SPDX | |
|---|---|---|
| Porté par | OWASP (standard Ecma, ECMA-424) | Linux Foundation (norme ISO/IEC 5962) |
| Point fort historique | sécurité : vulnérabilités, VEX, services | licences et conformité juridique |
| Formats de fichier | JSON, XML, Protocol Buffers | JSON, YAML, RDF, tag-value |
| Usage typique | suivi des vulnérabilités en continu | échange de conformité, open source |
Pour une PME dont l'objectif premier est de suivre les vulnérabilités, CycloneDX en JSON est le choix le plus simple. Le détail des différences est dans notre guide CycloneDX ou SPDX.
Comment générer un SBOM
Bonne nouvelle : vous n'avez pas à l'écrire. Il se génère automatiquement à partir de ce qui existe déjà.
- À partir du lockfile :
package-lock.json,poetry.lock,go.sum,Cargo.lock,composer.lock… Ce fichier contient déjà la liste exacte des versions installées. C'est la méthode la plus fiable pour les dépendances applicatives. - Avec un outil open source : Syft (Anchore) analyse un dossier ou une image Docker, cdxgen (OWASP CycloneDX) couvre de nombreux langages. Une commande suffit :
syft dir:. -o cyclonedx-json=sbom.cdx.json
syft registry.example.com/app:1.4.2 -o cyclonedx-json=image.cdx.json- Dans la CI, à chaque build, pour que l'inventaire suive le code sans intervention humaine. Notre tutoriel GitHub Actions et GitLab CI donne les fichiers prêts à copier.
L'erreur classique : le SBOM qui dort dans un dossier
Générer un SBOM une fois pour répondre à un questionnaire ne protège de rien. Sa valeur vient de sa confrontation régulière avec les bases de vulnérabilités, car une dépendance saine aujourd'hui peut être vulnérable demain sans que vous ayez changé une ligne de code.
C'est exactement la différence entre une photo et une caméra de surveillance. La photo montre l'état du jour où elle a été prise. La caméra vous prévient quand quelque chose change.
Un dispositif minimal efficace tient en trois éléments :
- un SBOM régénéré à chaque build (ou au moins à chaque livraison) ;
- une comparaison quotidienne avec une base à jour comme OSV, qui agrège GitHub Security Advisories, PyPA, RustSec, la base Go et le flux de paquets malveillants de l'OpenSSF ;
- une alerte ciblée sur ce qui est nouveau, avec la version corrigée, plutôt qu'une liste de 300 lignes que personne ne lit.
Et après : prioriser
Un premier SBOM confronté à OSV fait souvent apparaître des dizaines de vulnérabilités. Pas de panique : la plupart ne sont ni exploitées ni exploitables dans votre contexte. La méthode pour trier, avec les scores CVSS, EPSS et le catalogue KEV, est détaillée dans Prioriser les vulnérabilités.
Questions fréquentes
Un SBOM est-il obligatoire pour une PME ?
Cela dépend de votre activité. Le Cyber Resilience Act l'exige pour les fabricants de produits comportant des éléments numériques mis sur le marché européen, avec une application complète à partir du 11 décembre 2027. Pour les autres, il n'est pas imposé en tant que tel, mais c'est le moyen le plus simple de prouver la maîtrise de vos composants à un client, un assureur ou un auditeur NIS2 ou ISO 27001.
Quelle différence entre un SBOM et un lockfile ?
Le lockfile est propre à un gestionnaire de paquets (npm, pip, Cargo…) et sert à reproduire une installation. Le SBOM est un format standard, indépendant du langage, qui peut réunir plusieurs lockfiles, des paquets système et des images Docker dans un même document lisible par n'importe quel outil de sécurité.
Faut-il un SBOM par application ou un seul pour toute l'entreprise ?
Un par application ou par service livré, idéalement par version. C'est ce qui permet de répondre précisément à « quelle version de quel service est touchée ».
Peut-on partager son SBOM avec ses clients ?
Oui. Il ne contient pas de code source. Certaines entreprises l'accompagnent d'un document VEX qui précise quelles vulnérabilités connues ne s'appliquent pas à leur produit et pourquoi, ce qui évite des échanges inutiles avec les équipes sécurité des clients.