SBOM — Définition IT

Un SBOM (Software Bill of Materials, ou nomenclature logicielle) est un inventaire détaillé et structuré de tous les composants logiciels qui constituent une application : bibliothèques open source, dépendances, versions, licences, et leurs relations. C'est l'équivalent logiciel d'une nomenclature industrielle : pour chaque produit, on liste tous les sous-composants, leur origine et leur version.

Le SBOM est devenu un sujet stratégique avec la multiplication des attaques de la chaîne d'approvisionnement logicielle (Log4Shell en 2021, SolarWinds en 2020, xz-utils en 2024) et avec l'entrée en application du Cyber Resilience Act européen (2025-2027) et de DORA / NIS2 qui imposent une traçabilité des composants logiciels.

Pourquoi le SBOM compte

Une application moderne typique repose sur des centaines à des milliers de composants open source. Sans SBOM :

• •Quand une vulnérabilité comme Log4Shell est annoncée, impossible de savoir rapidement quelles applications sont impactées (qui contiennent quelle version vulnérable de log4j).
• •Lors d'un audit de conformité, impossible de prouver que l'on respecte les licences open source (GPL, AGPL, MIT, Apache).
• •En cas d'attaque de la supply chain (un mainteneur malveillant qui injecte du code malicieux dans une dépendance populaire), impossible de détecter rapidement la contamination.

Le SBOM transforme l'opaque « ça utilise X et Y, je crois » en « voici la liste exhaustive et auditable ».

Les standards de SBOM

Trois formats standards coexistent :

• •CycloneDX: (OWASP, 2017) : format JSON ou XML, conçu pour la sécurité, support des composants logiciels, matériels, services, données.
• •SPDX: (Linux Foundation, 2010) : standard ISO/IEC 5962:2021, format texte ou JSON, fort accent sur les licences.
• •SWID Tags: (ISO/IEC 19770-2) : format XML, plutôt orienté ITAM et inventaire d'installation.

CycloneDX et SPDX sont les plus utilisés en pratique. Les outils modernes savent émettre les deux.

Le contenu d'un SBOM

Un SBOM complet contient :

• •Composants: : nom, version, fournisseur, hash cryptographique (SHA-256).
• •Relations: : « ce composant dépend de », « est inclus dans ».
• •Licences: : SPDX ID des licences applicables.
• •Vulnérabilités connues: : références CVE (peut être dans un VEX associé).
• •Métadonnées: : auteur, date de génération, scope (application complète, conteneur, package).

SBOM et CRA (Cyber Resilience Act)

Le Cyber Resilience Act européen, en application progressive 2025-2027, impose aux fabricants de produits avec composants numériques :

• •Production d'un SBOM à jour pour chaque produit mis sur le marché européen.
• •Publication des vulnérabilités identifiées dans les 24 heures.
• •Patches gratuits pendant 5 ans minimum après la mise sur le marché.

Le SBOM devient donc un livrable réglementaire obligatoire, pas seulement une bonne pratique.

SBOM et VEX

Le VEX (Vulnerability Exploitability eXchange) complète le SBOM. Là où le SBOM dit « mon application contient log4j 2.14 », le VEX dit « et voici si la vulnérabilité Log4Shell est exploitable dans mon contexte » (par exemple : « non, car la fonction vulnérable n'est jamais appelée »).

VEX permet d'éviter la panique : la simple présence d'un composant vulnérable n'est pas équivalente à un risque exploitable.

Comment produire un SBOM

Plusieurs niveaux d'outillage :

• •CI/CD intégré: : Syft, CycloneDX CLI, Microsoft sbom-tool génèrent automatiquement le SBOM à chaque build.
• •Scan d'image conteneur: : Trivy, Grype, Snyk inspectent les images Docker.
• •Scan binaire: : Anchore, Black Duck analysent des binaires sans accès au code source.
• •Plateformes de gouvernance: : Sonatype, JFrog Xray, Mend, Snyk gèrent SBOM + vulnérabilités + licences à l'échelle.

Pour une démarche complète, le SBOM doit être :

• •Généré automatiquement à chaque build (pas une fois par an).
• •Signé: cryptographiquement (Sigstore).
• •Stocké: et versionné comme un livrable de release.
• •Confronté en continu: aux bases de vulnérabilités (CVE, GitHub Security Advisories, OSV).

SBOM et cartographie applicative

Le SBOM est à l'échelle d'une application. La cartographie applicative est à l'échelle du SI. Les deux se complètent :

• •La cartographie identifie « quelles applications j'ai ».
• •Le SBOM identifie « quels composants composent chaque application ».

L'enjeu pour une DSI est de fédérer les SBOM de toutes ses applications dans un graphe SI unique, exploitable pour la conformité (NIS2, DORA, CRA) et la réponse aux incidents (« quelles applications sont impactées par cette CVE ? »). Kabeen agrège automatiquement les SBOM de toutes les applications connues pour donner à la DSI une vue de risque consolidée.