SBOM (Software Bill of Materials) : quatre générateurs, quatre inventaires de la
même image

Décembre 2021, un vendredi soir. La CVE Log4Shell vient de tomber, note maximale, exploitable en une ligne, et déjà scannée en masse sur tout l'internet. Dans la war room improvisée, quelqu'un pose la seule question qui compte : "on utilise Log4j où, déjà ?". Silence. Log4j n'est presque jamais une dépendance qu'on installe soi-même : elle arrive en passager clandestin, tirée par un framework, lui-même tiré par un autre. Il a fallu des jours de grep pour établir une liste que personne n'avait sous la main. Cette liste porte un nom : un SBOM.

La réponse habituelle tient en une ligne : générez un SBOM à chaque build et le problème disparaît. Reste à savoir si deux générateurs produisent le même inventaire. On a donc fait tourner syft, trivy, osv-scanner et cdxgen sur quatre images Docker figées, avec la même règle de comptage pour tous. Sur l'image WebGoat, chaque outil trouve entre 305 et 335 composants, des totaux presque identiques. Mais il y a 438 composants distincts au total, et 220 seulement sont vus par les quatre. Le SBOM est le bon outil ; il dépend juste beaucoup plus qu'on ne le croit de celui qui le produit.

Le SBOM, c'est quoi exactement ?

Un SBOM (Software Bill of Materials, ou nomenclature logicielle) est l'inventaire, lisible par une machine, de tous les composants qui entrent dans un logiciel : chaque dépendance, sa version, souvent sa licence et son origine. Le code moderne n'est plus vraiment écrit, il est assemblé. Un projet web anodin déclare une poignée de dépendances directes, qui en tirent chacune d'autres, sur cinq ou six niveaux de profondeur. Là où votre package.json ne liste que ce que vous avez demandé explicitement, le SBOM énumère l'arbre complet, transitives comprises, avec les versions figées qui tournent vraiment.

Le point décisif, c'est "lisible par machine". Un SBOM n'est pas un document Word que quelqu'un tient à jour à la main ; c'est un fichier structuré (JSON ou XML) qu'on génère à partir du build et qu'on interroge par programme. Quand la prochaine faille type Log4Shell tombe, vous filtrez votre SBOM sur le nom du composant, et vous savez en quelques secondes quels produits et quelles versions sont concernés. À une condition, que la suite de cet article montre chiffres à l'appui : que le composant figure bien dans l'inventaire.

Normes SBOM : CycloneDX, SPDX, SWID

Pour qu'un outil génère un SBOM qu'un autre outil sait relire, il faut une grammaire commune. Trois formats standards se partagent le terrain, et le NTIA les reconnaît tous les trois comme lisibles par machine :

• CycloneDX, porté par l'OWASP, est né côté sécurité applicative. Il est compact, orienté analyse de risque, et gère nativement les dépendances, les vulnérabilités connues, les signatures et même les modèles de machine learning. Sa version courante est la 1.7, désormais standardisée sous ECMA-424 (deuxième édition, décembre 2025). C'est souvent le choix par défaut quand l'objectif est de corréler l'inventaire à des CVE.
• SPDX, standardisé par la Linux Foundation puis devenu la norme ISO/IEC 5962 (sur la base de SPDX 2.2.1, la version courante étant la 3.0), vient historiquement du monde de la conformité des licences open source. Plus verbeux, très rigoureux sur la traçabilité juridique.
• SWID (software identification tags), défini par la norme ISO/IEC 19770-2:2015, décrit un logiciel installé par des étiquettes standardisées. Plus orienté gestion de parc que corrélation aux vulnérabilités, il reste moins courant que CycloneDX et SPDX pour un SBOM applicatif.

Le débat entre formats importe moins qu'on ne le croit : les bons outils exportent dans plusieurs d'entre eux, et des convertisseurs font le pont. Voici à quoi ressemble un extrait CycloneDX, réduit à un seul composant pour la lisibilité :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-1c5d-4a2f-9b0e-1f2c8a4d5e6f",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "group": "org.apache.logging.log4j",
      "version": "2.14.1",
      "purl": "pkg:maven/org.apache.logging.log4j/[email protected]",
      "licenses": [
        { "license": { "id": "Apache-2.0" } }
      ]
    }
  ]
}

Le champ central, c'est le purl (package URL) : un identifiant normalisé qui décrit sans ambiguïté d'où vient le paquet (écosystème, nom, version). C'est la clé qui permet de confronter votre inventaire aux bases de vulnérabilités : un purl d'un côté, une vulnérabilité publiée sous un identifiant CVE indexée sur le même purl de l'autre. C'est aussi la clé qu'on a prise pour comparer les outils.

La mesure : quatre images, quatre générateurs, une règle

Quatre images publiques, tirées puis figées par digest le 7 octobre 2026 : debian:10, une image de base dont le support LTS a pris fin le 30 juin 2024, et trois applications volontairement vulnérables de l'OWASP, PyGoat v2.0.1 (Python, Django), Juice Shop v20.2.0 (Node.js) et WebGoat 2026 (Java, Spring Boot, sur une base Ubuntu 24.04). Chaque image a été exportée en archive avec docker save puis inventoriée par quatre outils libres, en configuration par défaut, une fois chacun :

syft scan docker-archive:webgoat-2026.tar -o syft-json
trivy image --input webgoat-2026.tar --scanners vuln --list-all-pkgs \
  --skip-db-update --skip-java-db-update --offline-scan
osv-scanner scan image --archive webgoat-2026.tar --offline-vulnerabilities --all-packages
FETCH_LICENSE=false cdxgen -t docker webgoat-2026.tar --no-install-deps

La règle de comptage a été écrite et horodatée avant le premier scan, et elle est la même pour les quatre. Un composant, c'est un triplet tiré du purl : type, nom, version, avec quelques normalisations documentées (minuscules, nom PyPI à la PEP 503, epoch Debian retiré). Le même paquet trouvé à trois chemins compte une fois. Les purl génériques, qui désignent des fichiers ou des dépôts apt plutôt que des paquets, sont mis à part. Et en cas de doute sur l'identité de deux composants, on ne fusionne pas. Grype n'apparaît pas dans ce comptage : il s'appuie sur l'inventaire de syft, même moteur.

Même total, pas le même inventaire

Commençons par le cas le plus propre. Sur debian:10, syft, trivy et osv-scanner listent exactement les mêmes 91 paquets. cdxgen en liste 128 : les mêmes 91, plus 37 que lui seul voit, surtout des paquets source Debian qu'il inscrit à côté des paquets binaires. Ce n'est pas une erreur, c'est une convention ; mais un SBOM qui compte 37 lignes de plus qu'un autre sur une image de 91 paquets surprendra le premier auditeur qui compare deux livraisons. PyGoat suit le même schéma, en plus gros : 144 composants vus par cdxgen seul, dont 137 paquets Debian.

WebGoat est l'image où la convergence apparente trompe le plus. Les quatre totaux tiennent dans une fourchette de 30 composants, et pourtant l'union en compte 438. Sur ces 438, 99 ne sont vus que par un outil (45 par cdxgen, 43 par osv-scanner, 8 par syft, 3 par trivy), dont 56 composants Maven et 43 paquets Debian ou Ubuntu. L'étude attribue ces écarts surtout à des conventions (nom retenu pour une archive, version, ce que chaque outil choisit de lister), sans les avoir résolus un par un, et la règle refuse de fusionner ce qu'elle ne peut pas identifier sans doute. Résultat : les quatre SBOM de la même image ne s'accordent que sur la moitié de leur union (50,2 %) quand on les compare ligne à ligne.

La conséquence pratique est simple. Si votre processus compare le SBOM livré par un fournisseur à celui que vous régénérez vous-même, faites-le avec le même outil, ou attendez-vous à des écarts qui ne disent rien de la sécurité du produit. Et choisissez un générateur, puis gardez-le : changer d'outil entre deux versions fabrique un diff d'inventaire qui n'existe pas dans le code.

Le trou npm de cdxgen : une option, pas un défaut

Le chiffre le plus spectaculaire du banc est aussi le plus facile à mal lire. Sur Juice Shop, une application Node.js, cdxgen 12.8.5 en mode image n'a inventorié aucun paquet npm. Les trois autres en trouvent entre 643 et 650. On pourrait en conclure que l'outil ne sait pas lire Node : c'est faux. Relancé sur la même archive avec l'option --deep, il en liste 655. Et en mode répertoire (-t js) sur l'arbre extrait, il en lit 1 167 depuis le package-lock.json, dépendances de développement comprises.

Le trou est propre à npm dans le mode par défaut : sur les mêmes réglages, cdxgen a bien lu les 47 paquets PyPI de PyGoat et 175 composants Maven de WebGoat. L'aide de l'outil présente bien --deep comme utile pour les images OCI, mais rien n'y annonce qu'un écosystème entier manquera sans elle. C'est exactement le genre de détail qui produit un SBOM vide d'un écosystème entier sans le moindre message d'erreur. La leçon vaut pour tous les outils : un inventaire se contrôle contre une source indépendante. Si le lockfile annonce plusieurs centaines de paquets et que le SBOM en compte dix-huit, le pipeline doit échouer, pas archiver.

Du SBOM aux CVE : d'accord sur le code, pas sur l'OS

L'inventaire n'est qu'une moitié du travail ; l'autre consiste à le confronter aux bases de vulnérabilités. Sur les mêmes images, grype, trivy et osv-scanner ont fait ce rapprochement. Sur les dépendances applicatives (PyPI, npm, Maven), ils s'accordent à 92,6 à 96,3 % : la grande majorité des CVE sont vues par les trois. Sur les paquets système anciens, l'accord s'effondre : 4 CVE communes sur 81 pour debian:10, 366 sur 1 359 pour les paquets Debian de PyGoat. Le détail, graphique compris, est dans notre comparatif des alternatives gratuites à Snyk. Pour le SBOM, la conclusion est que la qualité de l'inventaire système compte autant que celle de la base qu'on lui oppose.

Une fois l'inventaire produit, reste à trier sans se noyer dans les faux positifs. On a passé OWASP Dependency-Check et npm audit sur des projets de démonstration et sur WebGoat pour montrer ce que chacun remonte, et ce qu'il faut trier ensuite.

À quoi sert un SBOM, concrètement

Répondre en minutes à "suis-je affecté par la CVE X ?"

C'est l'usage roi, celui qui justifie à lui seul l'effort. Une faille critique est publiée sur un composant très répandu. Sans SBOM, chaque équipe part en fouille manuelle, projet par projet. Avec un SBOM tenu à jour, c'est une requête : quels artefacts embarquent ce purl, dans quelle version, sur quel périmètre. Avec la réserve que le banc impose : la requête ne trouve que ce que le générateur a inscrit.

Vérifier qu'aucun paquet malveillant n'est entré

Le même inventaire sert contre une menace d'une autre nature : le paquet publié pour nuire, qui n'a pas de faille à corriger. Le dépôt public ossf/malicious-packages recense ces paquets au format OSV, sous des identifiants MAL-, et un SBOM permet de croiser ses noms et versions avec cette liste. On a compté ses rapports sur une fenêtre de 24 mois, d'octobre 2024 à septembre 2026 : 212 790, dont 96,9 % pour npm.

Avant d'en faire un titre sur l'explosion des attaques, il faut regarder la date. Trois jours, le 11 et le 12 novembre et le 14 août 2025, concentrent 74,2 % de tous les rapports de la fenêtre. Ceux de novembre décrivent presque tous une seule campagne de spam, liée au protocole tea : des paquets republiés en masse sous des noms aléatoires pour gonfler des récompenses en jetons (140 698 des 140 770 rapports du 10 au 13 novembre). Ce sont de vrais paquets publiés par un acteur, signalés en bloc par Amazon Inspector, qui est crédité sur 92,1 % des rapports de la fenêtre. La médiane mensuelle, pics compris, tourne autour de 1 200 rapports.

Ce graphique ne dit donc pas quand les attaques ont lieu : il dit quand quelqu'un les a signalées, et par lots de quelle taille. Ce qui reste solide, c'est la répartition : npm écrase tous les autres registres, et un projet Node tire des centaines de paquets transitifs. C'est le contexte que détaille notre pilier sur les attaques de la supply chain logicielle.

Gérer les licences et prouver la conformité

L'autre moitié de l'histoire est juridique. Chaque dépendance vient avec une licence, et toutes ne se marient pas : une bibliothèque en GPL qui se glisse dans un produit propriétaire distribué, et c'est un problème de conformité. Le SBOM matérialise cet inventaire des licences. Il devient aussi une pièce contractuelle : un client grand compte ou une administration réclame de plus en plus souvent la nomenclature du logiciel qu'il achète.

Comment on génère un SBOM

On le dérive automatiquement, soit depuis les manifestes et lockfiles d'un projet, soit en inspectant un artefact déjà construit. Pour un projet Node, le premier réflexe tient dans une commande native :

# Node : lister l'arbre complet, versions résolues comprises
npm ls --all --json > dependencies.json

# Générer un vrai SBOM CycloneDX depuis le lockfile
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

L'approche par manifeste ne voit que ce qui est déclaré. Pour inventorier ce qui se trouve vraiment dans une image, paquets système compris, on scanne l'artefact final, par exemple avec syft (de la même famille que le scanner de vulnérabilités grype) :

# SBOM d'une image conteneur, au format CycloneDX
syft my-app:latest -o cyclonedx-json=sbom.cdx.json

# ... ou au format SPDX, selon ce que le destinataire attend
syft my-app:latest -o spdx-json=sbom.spdx.json

# Scanner un répertoire de code source plutôt qu'une image
syft dir:. -o cyclonedx-json

Le bon moment pour générer un SBOM, c'est à chaque build, dans la CI/CD, en même temps que l'artefact qu'il décrit, et avec un outil dont on a figé la version et les options. Les outils de SCA (analyse de composition logicielle) intègrent souvent cette étape : ils produisent le SBOM et enchaînent sur la corrélation aux vulnérabilités connues.

Le cadre réglementaire qui pousse le SBOM

Aux États-Unis, le décret présidentiel Executive Order 14028 de mai 2021, pris dans la foulée de l'affaire SolarWinds, a inscrit la fourniture d'un SBOM parmi les pratiques attendues des éditeurs qui vendent du logiciel au gouvernement fédéral ; une agence peut l'exiger à l'achat.

En Europe, c'est le Cyber Resilience Act. Le règlement inscrit dans ses exigences essentielles de gestion des vulnérabilités l'obligation pour le fabricant d'établir un SBOM dans un format courant et lisible par machine, couvrant au minimum les dépendances de premier niveau du produit. Il n'a pas à être publié, mais doit pouvoir être remis aux autorités de surveillance du marché. On détaille ce texte, ses échéances et ses sanctions dans notre article dédié au Cyber Resilience Act. Le banc ajoute une nuance que le texte ne traite pas : quatre SBOM de la même image, produits par des outils reconnus, ne s'accordent que sur la moitié de leurs composants.

Les limites : un SBOM ne vaut que tenu à jour et corrélé

La fraîcheur d'abord. Un SBOM décrit un état à un instant précis, et vos dépendances bougent à chaque déploiement. La corrélation ensuite. Un SBOM ne dit pas si un composant est vulnérable, il dit seulement qu'il est là : c'est le rôle de la SCA de le confronter en permanence aux bases publiées.

SBOM, SCA et sécurité de la supply chain

Le SBOM est l'inventaire, la SCA (Software Composition Analysis) en est l'analyse : elle confronte la liste aux bases de CVE, applique une politique (bloquer un build qui embarque une faille critique, alerter sur une licence interdite) et transforme la liste passive en signal actionnable. C'est ce que fait notre module d' analyse de composition logicielle, qui génère le SBOM depuis vos manifestes et enchaîne sur la corrélation aux vulnérabilités connues. Il ne fait pas partie de ce banc.

Cette corrélation continue est aussi la brique de base d'une gestion des vulnérabilités : on ne priorise et on ne remédie que ce qu'on a d'abord inventorié. Reste le pan que le SBOM et la SCA ne couvrent pas, ce qui se charge dans le navigateur de vos visiteurs, hors de tout manifeste. Pour le voir, il faut regarder la surface exposée depuis l'extérieur, en continu : c'est ce que fait notre module de sécurité de la chaîne d'approvisionnement, complémentaire du SBOM plutôt que concurrent.

Les limites de ce banc

• Pas de vérité terrain : on compare des inventaires entre eux. Personne ne sait combien de composants contient "vraiment" une image, donc aucun outil n'est déclaré meilleur.
• Configuration par défaut, une exécution : le cas cdxgen montre qu'une option change un écosystème entier. D'autres options auraient pu en changer d'autres.
• Quatre images, dont trois volontairement vulnérables et une image de base en fin de vie : elles ne représentent pas une application de production.
• Une règle d'identité stricte : ne pas fusionner en cas de doute gonfle les composants "vus par un seul outil". Une règle plus permissive réduirait l'écart, au prix de fusions incertaines.
• malicious-packages : la date retenue est celle du rapport, pas de l'attaque ni de la publication du paquet ; les imports en masse dominent les volumes.

À retenir

• Un SBOM est l'inventaire lisible par machine de tous les composants d'un logiciel. CycloneDX, SPDX et SWID en sont les formats standards, et le purl est la clé de corrélation aux CVE.
• Le générateur compte : sur WebGoat, 305 à 335 composants par outil, 438 au total, 220 vus par les quatre. Comparez des SBOM produits par le même outil, à version et options figées.
• Contrôlez l'inventaire contre le lockfile : cdxgen voyait 0 paquet npm sur Juice Shop sans --deep, et 655 avec. Un écosystème à zéro doit faire échouer le build.
• Sur le code, les scanners s'accordent (92,6 à 96,3 % des CVE applicatives vues par trois outils) ; sur les paquets système anciens, beaucoup moins.
• Les paquets malveillants se croisent aussi avec le SBOM, mais les volumes publiés mesurent le signalement : 74,2 % des 212 790 rapports de deux ans tombent sur trois jours.
• Le Cyber Resilience Act l'impose au fabricant (au minimum les dépendances de premier niveau), l'executive order américain l'attend des fournisseurs fédéraux ; il reste aveugle au code tiers chargé dans le navigateur.

Un SBOM propre vous dit de quoi vos produits sont faits. Il ne vous dit pas ce que vos pages chargent réellement chez vos visiteurs, ni quels composants tiers de votre surface exposée sont déjà vulnérables. C'est là que notre module de sécurité de la supply chain prend le relais, en continu et depuis l'extérieur. Envie d'en parler avec un humain qui manipule ces sujets au quotidien ? La page contact vous met en lien direct avec un pentester.

Questions fréquentes sur le SBOM