xBOM : comprendre l'écosystème des inventaires CycloneDX

Vous avez un SBOM pour chaque image Docker. Vous pensez avoir une visibilité complète sur vos composants. Pourtant, quand une vulnérabilité critique touche une dépendance, vous réalisez que votre SBOM décrit ce qui a été buildé, pas ce qui tourne réellement en production.

Le SBOM (Software Bill of Materials) est indispensable, mais il ne raconte qu’une partie de l’histoire. Pour une visibilité complète sur votre supply chain, vous avez besoin de comprendre l’écosystème xBOM — l’ensemble des inventaires spécialisés que CycloneDX propose au-delà du SBOM.

Dans ce guide, vous découvrirez :

Pourquoi le SBOM seul ne suffit pas et ses limites concrètes
Les principaux types de BOM de l’écosystème CycloneDX les plus utiles pour les équipes produit et sécurité : SBOM, OBOM, SaaSBOM, HBOM, CBOM et ML-BOM
Quel BOM utiliser selon votre contexte : développeur, SecOps, architecte ou RSSI
Comment combiner ces inventaires pour une traçabilité bout en bout

Prérequis

Lecture du guide SBOM : comprendre le Software Bill of Materials
Notions de base sur la supply chain security

Pourquoi le SBOM ne suffit plus

Le problème : build-time ≠ runtime

Un SBOM classique est généré au moment du build. Il décrit :

Les dépendances déclarées dans package.json, requirements.txt, go.mod
Les paquets installés dans l’image Docker au moment de la construction
Les bibliothèques liées statiquement ou dynamiquement

Mais en production, la réalité est différente :

Ce que le SBOM capture	Ce qu’il manque
Dépendances au build	Dépendances chargées dynamiquement au runtime
Image Docker telle que buildée	Configuration runtime, variables d’environnement
Code source analysé	Services externes appelés (API, SaaS)
Librairies embarquées	Firmware des équipements connectés
Algorithmes cryptographiques dans le code	Cipher suites négociées en production

Exemple concret : le décalage build/runtime

Imaginons une application Python Flask :

import importlib
import os

# Chargement dynamique d'un module selon l'environnement
module_name = os.getenv("PLUGIN_MODULE", "default_plugin")
plugin = importlib.import_module(module_name)

Dans ce cas :

Le SBOM généré au build listera flask, importlib, etc.
Il ne contiendra pas le module plugin_production chargé dynamiquement en production
Si ce module contient une vulnérabilité, vous ne le saurez pas via le SBOM

Les limites du SBOM en un tableau

Limite	Conséquence	Solution
Build-time only	Pas de visibilité runtime	OBOM
Software only	Pas de visibilité hardware	HBOM
Pas de services externes	SaaS et API invisibles	SaaSBOM
Pas de crypto	Algorithmes obsolètes non détectés	CBOM
Pas de modèles ML	Supply chain IA non traçée	ML-BOM
Pas de visibilité pipeline	Images, templates et composants CI/CD invisibles	PBOM / SLSA provenance

L’écosystème xBOM de CycloneDX

xBOM (eXtended Bill of Materials) est le terme utilisé par CycloneDX pour désigner l’ensemble des types de BOM disponibles. CycloneDX est un standard OWASP, normalisé ECMA-424, qui permet de représenter différents types d’inventaires dans un format unifié.

Vue d’ensemble des principaux types de BOM

Écosystème xBOM CycloneDX : SBOM, OBOM, SaaSBOM, HBOM, CBOM, ML-BOM

SBOM — Software Bill of Materials

Ce que c’est : L’inventaire des composants logiciels au moment du build.

Ce qu’il contient :

Nom, version, éditeur de chaque composant
Identifiants stables (purl, CPE)
Dépendances directes et transitives
Licences
Hashes des fichiers

Quand l’utiliser :

À chaque build d’artefact (image Docker, binaire, package)
Pour alimenter les scans de vulnérabilités
Pour répondre aux exigences de conformité (CRA, NIS2)

Outils : Syft, Trivy, cdxgen

OBOM — Operations Bill of Materials

Ce que c’est : L’inventaire de ce qui tourne réellement en production, incluant les configurations runtime.

Ce qu’il contient :

Dépendances chargées dynamiquement
Variables d’environnement actives
Configurations runtime (fichiers de config lus au démarrage)
État des services déployés
Connexions et intégrations actives

Quand l’utiliser :

Pour compléter le SBOM avec la réalité production
Pour auditer les environnements de staging/production
Pour détecter les dérives entre build et runtime

Différence clé avec le SBOM :

Aspect	SBOM	OBOM
Moment de génération	Build	Runtime
Source de vérité	Code/manifestes	Environnement déployé
Contenu	”Ce qui est prévu"	"Ce qui tourne”
Fréquence de génération	À chaque build	Continue ou périodique

SaaSBOM — Services Bill of Materials

Ce que c’est : L’inventaire des services, APIs et endpoints qui soutiennent votre application — qu’ils soient internes ou externes.

Ce qu’il contient :

Services SaaS tiers (Stripe, Auth0, Datadog, etc.)
APIs internes et externes appelées
Microservices et fonctions serverless
Endpoints et flux de données
Protocoles et certificats utilisés
Classifications de données transitant par ces services

Quand l’utiliser :

Pour cartographier les dépendances de service (internes et externes)
Pour évaluer le risque fournisseur (TPRM)
Pour la conformité RGPD (flux de données)
Pour le threat modeling
Pour documenter une architecture microservices

Exemple de ce qu’un SaaSBOM capture :

{
  "services": [
    {
      "name": "Stripe Payment Gateway",
      "provider": "Stripe Inc.",
      "endpoints": ["api.stripe.com"],
      "data": ["credit_card", "pii"],
      "authentication": "oauth2",
      "trustZone": "external"
    },
    {
      "name": "Auth0 Identity",
      "provider": "Okta Inc.",
      "endpoints": ["your-tenant.auth0.com"],
      "data": ["user_credentials", "tokens"],
      "authentication": "oidc"
    }
  ]
}

HBOM — Hardware Bill of Materials

Ce que c’est : L’inventaire des composants matériels, firmware et configurations physiques.

Ce qu’il contient :

Processeurs, contrôleurs, modules embarqués
Versions de firmware
Configurations matérielles
Équipements IoT et ICS
Liens avec les éléments logiciels associés

Quand l’utiliser :

Secteurs IoT, industriel, médical, automotive
Conformité sécurité des équipements (IEC 62443, FDA)
Gestion des vulnérabilités firmware
Traçabilité de la supply chain physique

Cas d’usage typique : Un dispositif médical connecté contient un microcontrôleur avec un firmware spécifique. L’HBOM documente ce matériel et permet de tracker les mises à jour de firmware nécessaires.

CBOM — Cryptography Bill of Materials

Ce que c’est : L’inventaire des actifs cryptographiques utilisés par le système.

Ce qu’il contient :

Algorithmes de chiffrement utilisés (AES, RSA, etc.)
Protocoles (TLS, SSH, etc.)
Certificats et leur cycle de vie
Clés et leur statut (actives, archivées, compromises)
Dépendances cryptographiques entre composants

Quand l’utiliser :

Préparation à la cryptographie post-quantique (PQC)
Audit de conformité cryptographique
Détection d’algorithmes obsolètes (SHA-1, MD5, RC4)
Gestion centralisée des certificats

Pourquoi c’est crucial pour la transition PQC :

Les ordinateurs quantiques rendront obsolètes les algorithmes asymétriques actuels (RSA, ECC). Un CBOM permet de :

Inventorier tous les usages cryptographiques
Identifier les algorithmes vulnérables au quantique
Planifier la migration vers des algorithmes post-quantiques
Vérifier que les nouvelles implémentations sont correctes

ML-BOM — Machine Learning Bill of Materials

Ce que c’est : L’inventaire des composants d’un système d’intelligence artificielle.

Ce qu’il contient :

Modèles ML utilisés (architecture, version, provenance)
Datasets d’entraînement (source, licence, biais potentiels)
Frameworks ML (TensorFlow, PyTorch, etc.)
Pipelines d’entraînement et de déploiement
Dépendances entre modèles

Quand l’utiliser :

Conformité AI Act européen
Traçabilité des modèles en production
Audit des biais et de l’éthique IA
Sécurisation de la supply chain ML (model poisoning, dataset tampering)

Exemple de risques supply chain ML :

Risque	Description	Comment ML-BOM aide
Model poisoning	Modèle pré-entraîné compromis	Traçabilité de la provenance
Dataset tampering	Données d’entraînement modifiées	Inventaire des sources de données
Dependency confusion	Package ML malveillant	Visibilité sur les dépendances
License violation	Modèle commercial utilisé sans licence	Suivi des licences

Quel BOM pour quel usage ?

Matrice de décision par rôle

Rôle	BOM principal	BOM secondaires	Cas d’usage
Développeur	SBOM	-	Connaître ses dépendances, corriger les CVE
DevSecOps	SBOM + OBOM	CBOM	Visibilité build + runtime, audits
Architecte	SaaSBOM	SBOM, HBOM	Cartographie système, threat modeling
RSSI/GRC	Tous	-	Vision complète, conformité, risques
Équipe IoT/OT	HBOM	SBOM, CBOM	Sécurité équipements, firmware
Équipe ML/IA	ML-BOM	SBOM	Traçabilité modèles, conformité AI Act

Matrice de décision par contexte technique

Contexte	BOM requis	Pourquoi
Application web classique	SBOM	Inventaire composants
Application + services externes	SBOM + SaaSBOM	+ Dépendances externes
Application critique en prod	SBOM + OBOM	+ Réalité runtime
Application avec chiffrement	SBOM + CBOM	+ Audit crypto
IoT / Embarqué	SBOM + HBOM	+ Matériel et firmware
Système ML/IA	SBOM + ML-BOM	+ Modèles et datasets
Système complet à auditer	Tous	Vision 360°

Comment combiner les BOM en pratique

Architecture de corrélation

L’idée n’est pas de générer tous les BOM indépendamment, mais de les lier pour avoir une vision cohérente :

Architecture de corrélation xBOM : GUAC et Dependency Track

Workflow pratique en 4 étapes

Générer le SBOM au build

À chaque build CI/CD, générez un SBOM avec Syft ou cdxgen :
Fenêtre de terminal
```
syft . -o cyclonedx-json > sbom.cdx.json
```
Enrichir avec l’OBOM en staging/production

Collectez les informations runtime (configurations, modules chargés, variables d’environnement) et générez un OBOM qui complète le SBOM.
Documenter les services externes (SaaSBOM)

Pour chaque intégration tierce, documentez le service, les données échangées, les protocoles utilisés.
Corréler dans un outil centralisé
- GUAC : graphe de connaissances pour corréler SBOM, VEX, provenance et construire des relations avancées entre artefacts
- Dependency-Track : exploitation SBOM/VEX, pilotage des vulnérabilités et conformité — moins orienté corrélation multi-domaines, mais excellent pour le suivi opérationnel

Outils pour générer chaque type de BOM

Type de BOM	Outils	Notes
SBOM	Syft, Trivy, cdxgen, Grype	Maturité élevée, bien supporté
OBOM	cdxgen (expérimental), collecte manuelle	Encore émergent
SaaSBOM	cdxgen, documentation manuelle	Nécessite souvent une cartographie manuelle
HBOM	Outils constructeurs, documentation manuelle	Spécifique au secteur
CBOM	Cryptosense, IBM Crypto Analyzer, cdxgen	En développement actif
ML-BOM	cdxgen, CycloneDX ML tools	Support croissant

Conformité et réglementations

Impact sur CRA et NIS2

Le Cyber Resilience Act (CRA) européen impose, à l’annexe II, que les fabricants mettent à disposition des informations indiquant où le SBOM est accessible. C’est une formalisation de l’importance du SBOM dans la documentation technique, mais le règlement ne prescrit pas explicitement un “xBOM complet”.

En pratique, de nombreuses organisations vont au-delà du seul SBOM pour mieux couvrir le runtime, les services tiers, la crypto ou l’IA :

Exigence CRA	BOM pertinent	Obligatoire / Recommandé
Inventaire des composants	SBOM	Explicite (Annexe II)
Gestion des vulnérabilités	SBOM + VEX	Explicite
Documentation complète	SBOM + extensions	Interprétation prudente
Sécurité par défaut	CBOM (crypto sûre)	Recommandé

Pour NIS2, le lien avec la gestion des dépendances et des tiers est plus général — via la gestion des risques de la supply chain — mais sans obligation explicite de type “SaaSBOM”. La connaissance des dépendances externes reste néanmoins une bonne pratique pour répondre à l’esprit du règlement.

Vers un SBOM étendu obligatoire ?

Les réglementations évoluent vers une vision plus large que le SBOM seul, mais les textes restent prudents :

CRA : formalise le SBOM, encourage implicitement une documentation plus complète
FDA (médical) : recommande SBOM + CBOM pour les dispositifs médicaux
NIST 800-161 : framework C-SCRM incluant la gestion des tiers

À retenir

Les 5 points essentiels de ce guide :

Le SBOM décrit le build, pas le runtime — il ne capture pas les plugins chargés dynamiquement, les configurations runtime, ni les services externes
L’écosystème xBOM de CycloneDX propose plusieurs types de BOM complémentaires (SBOM, OBOM, SaaSBOM, HBOM, CBOM, ML-BOM, et d’autres comme MBOM, VDR, BOM-Link)
Chaque BOM répond à un besoin spécifique — choisissez selon votre contexte (développeur, SecOps, IoT, ML)
La puissance vient de la corrélation — SBOM + OBOM + VEX + policies dans un outil comme GUAC
Les réglementations formalisent le SBOM — le CRA l’impose explicitement ; aller vers un xBOM plus large reste une démarche de maturité, pas une obligation immédiate

Prochaines étapes

OBOM runtime

Apprenez à générer un inventaire runtime pour compléter votre SBOM [Guide OBOM à venir]

GUAC

Corrélez SBOM, VEX et provenance dans un graphe de connaissances Lire le guide GUAC

VEX

Enrichissez vos SBOM avec le contexte d’exploitabilité des vulnérabilités Lire le guide VEX

CBOM cryptographie

Inventoriez vos actifs cryptographiques pour la transition post-quantique [Guide CBOM à venir]