Provetry
ENDEDemander l’accès anticipé
Test gratuit
Demander l’accès anticipé

Provetry ouvre en novembre 2026. Le test CRA gratuit, les outils et les guides sont disponibles dès maintenant.

Qu’est-ce qu’un SBOM ? Définition, formats, exemple et outils

8 min de lecture

Sur cette page
  1. Pourquoi c’est important
  2. Ce que contient un SBOM
  3. Les deux formats : CycloneDX et SPDX
  4. Un court exemple
  5. Les types de SBOM
  6. Comment en produire un
  7. Un SBOM n’est qu’un point de départ
  8. Ce que fait Provetry
  9. Sources

Un SBOM (software bill of materials, ou nomenclature logicielle) est la liste de tout ce qui compose un logiciel : chaque bibliothèque, framework, environnement d’exécution et paquet, avec sa version exacte, son fournisseur et sa place par rapport au reste. C’est la liste des ingrédients d’un produit, écrite dans un format qu’une machine sait lire.

L’idée vient de l’industrie, où la nomenclature recense chaque pièce d’un produit physique. Un logiciel s’assemble de la même façon : une application écrite aujourd’hui est surtout faite de composants open source, souvent des centaines une fois comptées les dépendances des dépendances.

Pourquoi c’est important

Quand une vulnérabilité grave est publiée dans une bibliothèque très utilisée, la première question que reçoit chaque éditeur est : sommes-nous touchés ? Sans SBOM, y répondre veut dire fouiller à la main les dépôts, les fichiers de build et les images de conteneurs, pour chaque produit et chaque version encore en service. Avec un SBOM, c’est une recherche.

C’est pourquoi le SBOM est passé de bonne pratique à obligation :

  • Dans l’Union européenne, le Cyber Resilience Act impose aux fabricants d’établir un SBOM pour chaque produit comportant des éléments numériques ; voir ce que le CRA attend d’un SBOM.
  • Aux États-Unis, les agences fédérales peuvent l’exiger dans leurs contrats de logiciels, une pratique lancée par le décret présidentiel 14028 en 2021 et laissée depuis janvier 2026 au choix de chaque agence.
  • Les grands clients le demandent de plus en plus dans leurs conditions d’achat, quoi que dise la loi.

Ce que contient un SBOM

Pour chaque composant, un SBOM utile donne :

Champ Exemple
Nom express
Version 4.19.2
Fournisseur l’éditeur du composant
Un identifiant unique une URL de paquet (purl) comme pkg:npm/express@4.19.2
Une empreinte un SHA-256 ou SHA-512 du fichier livré
Licence MIT
Relation dépendance directe du produit, ou apportée par un autre composant

Et pour le SBOM lui-même : le produit et la version qu’il décrit, qui l’a produit, quand, et avec quel outil.

Ces champs reprennent les éléments minimaux publiés en 2021 par la NTIA américaine (fournisseur, nom, version, identifiant unique, relation de dépendance, auteur du SBOM, horodatage). La CISA les a remplacés en 2026 par une liste mise à jour, qui ajoute notamment l’empreinte du composant, la licence, le nom de l’outil et le contexte dans lequel le SBOM a été produit. Le BSI allemand va plus loin dans sa directive technique TR-03183-2, écrite en pensant au CRA.

L’URL de paquet mérite un mot : c’est l’identifiant qui permet à un outil de rapprocher un composant des bases de vulnérabilités sans deviner. Un SBOM qui dit seulement « openssl 3.0 » laisse place à l’erreur ; pkg:deb/debian/openssl@3.0.11-1~deb12u2, non.

Les deux formats : CycloneDX et SPDX

Deux normes ouvertes dominent, et tout outil sérieux lit les deux.

CycloneDX est né à l’OWASP en 2017, pensé pour la sécurité. C’est aujourd’hui une norme d’Ecma International, ECMA-424 ; sa version actuelle, 1.7, en est la deuxième édition. Il transporte les informations de vulnérabilité et d’exploitabilité (VEX) et décrit aussi des services, du matériel, des modèles d’apprentissage automatique et de la cryptographie.

SPDX vient de la Linux Foundation et a commencé par la conformité des licences open source. Sa version 2.2.1 est une norme ISO, ISO/IEC 5962:2021 ; la version actuelle est la 3.0.1, qui a ajouté des profils pour la sécurité, l’IA et les jeux de données.

Lequel choisir ? Sans contrainte, CycloneDX est le choix le plus courant pour la sécurité ; SPDX est souvent celui que les juristes utilisent déjà pour les licences. Les deux s’écrivent en JSON (le choix habituel) ou en XML, et passer de l’un à l’autre est possible, avec quelques pertes de détail. Le BSI allemand accepte CycloneDX 1.6 ou plus récent et SPDX 3.0.1 ou plus récent.

Un court exemple

Voici un SBOM CycloneDX minimal, en JSON, pour un produit qui dépend d’une bibliothèque :

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-11-08T09:00:00Z",
    "tools": { "components": [{ "type": "application", "name": "cdxgen" }] },
    "component": { "bom-ref": "gateway", "type": "application", "name": "Gateway", "version": "4.2.0",
      "supplier": { "name": "Acme Devices" } }
  },
  "components": [
    { "bom-ref": "express", "type": "library", "name": "express", "version": "4.19.2",
      "purl": "pkg:npm/express@4.19.2", "licenses": [{ "license": { "id": "MIT" } }] }
  ],
  "dependencies": [{ "ref": "gateway", "dependsOn": ["express"] }]
}

Le bloc metadata décrit le produit et la façon dont le SBOM a été produit ; components liste ce qu’il contient ; dependencies dit comment tout cela est relié. Un vrai SBOM a la même forme, avec des centaines de composants. Vous pouvez ouvrir le vôtre dans notre visionneuse et vérificateur de SBOM gratuit, qui liste aussi les champs manquants.

Les types de SBOM

Un même produit peut être décrit à différents moments, et le résultat change. La CISA distingue six types :

  • Conception : ce que vous prévoyez d’utiliser, avant que le code existe.
  • Source : lu dans le code source et ses manifestes.
  • Build : produit pendant la construction de la version, à partir de ce que le build a réellement récupéré. En général le plus fidèle pour un logiciel.
  • Analysé : reconstruit après coup en analysant un binaire ou une image.
  • Déployé : ce qui est installé sur un système donné.
  • Exécution : ce qui est réellement chargé quand le logiciel tourne.

Pour un fabricant, c’est le SBOM de build de chaque version qui compte : il décrit ce que vous livrez.

Comment en produire un

N’écrivez pas un SBOM à la main. Produisez-le dans votre chaîne de build, à chaque version, à partir de vos fichiers de verrouillage et des images que vous livrez. Parmi les générateurs open source les plus utilisés :

  • Syft (Anchore) : images de conteneurs et systèmes de fichiers, nombreux écosystèmes.
  • cdxgen (OWASP CycloneDX) : dépôts de code dans de nombreux langages.
  • Trivy (Aqua Security) : images, systèmes de fichiers et dépôts, avec l’analyse des vulnérabilités intégrée.
  • Les extensions CycloneDX pour Maven, Gradle, npm, .NET, Python et d’autres, qui travaillent depuis le build.
  • sbom-tool de Microsoft, pour SPDX.
  • Pour essayer sans rien installer : notre générateur de SBOM gratuit transforme vos fichiers de verrouillage en CycloneDX ou SPDX dans votre navigateur, avec provetry-core, le moteur open source de Provetry.

Quel que soit l’outil, vérifiez trois choses dans le résultat : chaque composant a une version et une URL de paquet, les dépendances indirectes sont listées et pas seulement les directes, et le SBOM nomme le produit et la version auxquels il appartient.

Les commandes et les pièges de chaque écosystème ont leur propre guide : npm, pnpm et Yarn, Python, Java, Rust, Go, .NET et images de conteneur.

Un SBOM n’est qu’un point de départ

Seul, un SBOM ne fait rien. Sa valeur vient de ce que vous en faites :

  1. Gardez-en un par version, pour pouvoir dire quelles versions en circulation contiennent un composant.
  2. Rapprochez-le chaque jour des données de vulnérabilités : de nouvelles failles sont publiées sur des composants livrés il y a des mois. Priorisez avec le score EPSS et les listes de vulnérabilités exploitées.
  3. Notez vos conclusions quand un composant vulnérable est présent mais inexploitable dans votre produit : c’est le rôle d’une déclaration VEX.
  4. Partagez-le quand on vous le demande, à vos clients ou aux autorités. Rien ne vous oblige à le publier.

Ce que fait Provetry

Provetry établit le SBOM de chaque version depuis votre CI ou à partir des fichiers que vous envoyez, en CycloneDX et en SPDX, garde le SBOM de chaque version, rapproche chaque jour chaque composant des vulnérabilités nouvelles et exploitées, et enregistre vos décisions VEX. L’offre gratuite couvre un produit.

Sources