SBOM

01 — DéfinitionQu'est-ce qu'un SBOM ?

Un SBOM (Software Bill of Materials, littéralement « nomenclature logicielle ») est un inventaire structuré et exhaustif de tous les composants qui constituent une application ou un système logiciel. Le terme est emprunté à l'industrie manufacturière où le Bill of Materials désigne la nomenclature des pièces d'un produit — une voiture a un BOM qui liste tous ses composants avec leurs références.

Appliqué au logiciel, un SBOM contient typiquement pour chaque composant :

• Nom du composant (ex. log4j-core).
• Version précise (ex. 2.14.1).
• Fournisseur ou éditeur.
• Identifiant unique (PURL, CPE, hashes).
• Licence (MIT, Apache 2.0, GPL, propriétaire).
• Relations de dépendance avec les autres composants.
• Auteur du SBOM et horodatage.

Un projet logiciel moderne contient typiquement des centaines à des milliers de composants : dépendances directes (celles que l'équipe a explicitement ajoutées) et surtout les dépendances transitives (dépendances des dépendances, récursivement). Une application web Node.js peut tirer plus de 1 000 packages npm sans effort ; un container Docker en inclut souvent des milliers. Le SBOM révèle cette réalité souvent méconnue des équipes elles-mêmes.

Le SBOM n'est pas une invention récente — les pratiques existent depuis longtemps dans l'open source (fichiers package.json, requirements.txt, pom.xml) — mais la formalisation structurée et standardisée est devenue essentielle après les incidents majeurs de supply chain attack de 2020-2021.

Avant Log4Shell, la question « Log4j est-il dans mes systèmes ? » pouvait demander des semaines de recherche manuelle dans une grande organisation. Avec un SBOM à jour, la réponse prend quelques secondes.

02 — ContextePourquoi le SBOM est devenu critique

SolarWinds (décembre 2020)

Point de bascule dans la prise de conscience des risques de supply chain. Le groupe APT29 (Cozy Bear, attribué au SVR russe) a injecté un backdoor (SUNBURST) dans les mises à jour officielles du logiciel Orion de SolarWinds. Environ 18 000 organisations ont installé la version compromise, dont le Pentagone, le Département d'État, Microsoft, Cisco, Intel, et de nombreuses entreprises du Fortune 500. Les victimes ont découvert la compromission des mois après — elles ignoraient totalement la présence de code malveillant dans un composant apparemment légitime de leur chaîne d'approvisionnement.

L'incident a révélé trois problèmes majeurs :

• Beaucoup d'organisations ne savaient pas exactement quels logiciels elles utilisaient.
• Encore moins savaient quels composants composaient ces logiciels.
• La visibilité manquait pour identifier rapidement les versions vulnérables à déployer en urgence.

Log4Shell (décembre 2021)

Vulnérabilité critique (CVE-2021-44228, CVSS 10/10) dans Log4j, bibliothèque de journalisation Java utilisée dans des dizaines de milliers de produits : applications d'entreprise, systèmes embarqués, jeux vidéo (Minecraft), middleware, etc. Exploitation extrêmement simple et massive dès sa divulgation. Le choc : la plupart des organisations ne savaient pas si et où elles utilisaient Log4j. Des semaines de recherche manuelle ont été nécessaires dans de nombreuses grandes organisations pour inventorier leur exposition.

Autres incidents révélateurs

• Codecov (2021) : compromission d'un outil CI/CD utilisé par 29 000 organisations, incluant des credentials exfiltrés.
• Kaseya VSA (2021) : ransomware via RMM, affectant MSP et leurs milliers de clients en cascade.
• 3CX (mars 2023) : attaque cascade double — Trading Technologies X_TRADER compromis, puis 3CX via un employé ayant installé X_TRADER, puis ~12 millions d'utilisateurs finaux de 3CX potentiellement exposés.
• XZ Utils backdoor (mars 2024) : backdoor sophistiqué dans la bibliothèque de compression XZ, injecté sur 2 ans par un contributeur patient, détecté in extremis avant déploiement massif dans les distributions Linux de production. A révélé la fragilité des projets open source maintenus par peu de personnes.

Réaction gouvernementale — Executive Order 14028

En mai 2021, le président Biden publie l'Executive Order 14028 « Improving the Nation's Cybersecurity » qui marque un tournant : tout logiciel vendu au gouvernement fédéral américain doit être accompagné d'un SBOM. La NTIA (puis CISA) a défini les exigences minimales pour un SBOM utilisable (minimum elements).

Réaction européenne — Cyber Resilience Act

Adopté définitivement en octobre 2024, le Cyber Resilience Act (CRA) de l'UE impose des exigences de cybersécurité pour tous les produits avec éléments numériques (matériel et logiciel) commercialisés en Europe. Parmi les obligations : tenir un SBOM à jour pour la durée de vie du produit, notifier rapidement les vulnérabilités exploitées, documenter les composants. Application progressive avec pleine vigueur en 2027.

NIS2 et responsabilité chain d'approvisionnement

La directive NIS2 impose aux entités essentielles et importantes la gestion des risques liés à la chaîne d'approvisionnement (article 21). En pratique, cela implique pour les grands donneurs d'ordre : exiger des SBOM de leurs fournisseurs logiciels, les intégrer dans leurs contrats, effectuer des analyses de vulnérabilités sur les composants tiers.

03 — FormatsLes deux standards dominants

SPDX — Software Package Data Exchange

Maintenu par la Linux Foundation depuis 2010. Standardisé comme ISO/IEC 5962 en 2021. Orienté historiquement vers la gestion de licences open source : savoir précisément quelles licences s'appliquent à un produit composite. L'adoption dans les communautés Linux historiques est très large.

Caractéristiques :

• Formats : JSON, YAML, RDF, tag-value, spreadsheet.
• Version actuelle : SPDX 3.0 publié en 2024, architecture modulaire avec profils (Build, Security, Lite, AI, Dataset).
• Identifiants licences SPDX : référence mondiale utilisée au-delà de SPDX (ex. MIT, Apache-2.0, GPL-3.0-or-later).
• Support solide pour les méta-données juridiques.

CycloneDX — OWASP

Maintenu par l'OWASP depuis 2017. Nativement conçu pour la sécurité et la supply chain plus que pour les licences. En 2026, plus largement adopté dans les outils DevSecOps (Snyk, GitHub, Dependency-Track, Trivy, Syft).

Caractéristiques :

• Formats : JSON (principal), XML, protobuf.
• Version actuelle : CycloneDX 1.6 (publiée 2024).
• Support natif des VEX (Vulnerability Exploitability eXchange) pour déclarer l'exposition ou non à chaque vulnérabilité.
• Support étendu au-delà du logiciel : BOM de conteneurs, bibliothèques cryptographiques (CBOM), matériel (HBOM), données d'entraînement IA (AI-BOM), services (SaaSBOM).
• Intégration serrée avec les scanners de vulnérabilités.

PURL — Package URL

Standard essentiel mais souvent méconnu : le PURL (Package URL) fournit une manière unique d'identifier un package, indépendante du format de SBOM. Syntaxe :

• pkg:npm/log4js@6.4.1
• pkg:maven/org.apache.logging.log4j/log4j-core@2.17.2
• pkg:pypi/django@4.2.0
• pkg:docker/debian@bullseye

PURL est maintenant le format d'identifiant dominant pour les SBOM, plus expressif et moins ambigu que le CPE historique (utilisé par NVD).

CBOM, HBOM, AI-BOM, SaaSBOM

Extensions émergentes du concept SBOM :

• CBOM : Cryptographic Bill of Materials. Inventaire des primitives cryptographiques utilisées. Crucial pour la transition post-quantique.
• HBOM : Hardware Bill of Materials. Pour les produits physiques avec électronique.
• AI-BOM : composants d'un système IA — modèles, données d'entraînement, prompts système, outils.
• SaaSBOM : services tiers utilisés par une application SaaS.
• OBOM (Operations BOM) : composants de l'environnement d'exécution (OS, containers, services).

CycloneDX supporte nativement plusieurs de ces extensions. SPDX 3.0 a ajouté des profils dédiés.

Choisir SPDX ou CycloneDX ?

• Contexte conformité US, open source Linux historique, focus licences : SPDX reste dominant.
• Contexte DevSecOps, focus vulnérabilités, outils modernes, supply chain : CycloneDX est plus adapté.
• En pratique : les deux sont pleinement compatibles avec EO 14028 et CRA. Les outils modernes génèrent les deux à la demande. Des convertisseurs SPDX↔CycloneDX existent.

04 — RéglementationObligations en France et dans l'UE

US Executive Order 14028 (mai 2021)

Premier cadre réglementaire majeur imposant les SBOM. Applicable à tout logiciel vendu aux agences fédérales US. Exigences minimales définies par NTIA : données de base (nom, version, fournisseur, relations), formats standards, génération automatisée. Impact indirect sur les fournisseurs européens vendant aux USA.

EU Cyber Resilience Act — CRA (2024)

Adopté le 10 octobre 2024. Application progressive :

• Depuis fin 2024 : entrée en vigueur.
• Septembre 2026 : obligations de notification de vulnérabilités.
• Décembre 2027 : application complète.

Le CRA impose aux fabricants de produits avec éléments numériques (matériel et logiciel vendu dans l'UE) :

• Exigences essentielles de cybersécurité « by design ».
• Tenir un SBOM au moins pour les composants de niveau supérieur, dans un format standard lisible par machine.
• Notifier activement les vulnérabilités exploitées dans les 24h à l'ENISA.
• Fournir des correctifs pendant la durée de support (minimum 5 ans pour certains produits).
• Documentation technique et marquage CE.

Sanctions maximales : 15 millions d'euros ou 2,5% du chiffre d'affaires mondial — niveau RGPD.

NIS2 et chaîne d'approvisionnement

NIS2 (article 21.2.d) impose aux entités essentielles et importantes d'inclure dans leurs mesures de gestion des risques : la sécurité de la chaîne d'approvisionnement, y compris les aspects liés aux relations avec les fournisseurs directs et aux prestataires de services. En pratique, cela conduit à : clauses SBOM dans les contrats fournisseurs, audits de chaîne d'approvisionnement, intégration au registre des risques.

DORA (secteur financier)

DORA (règlement 2022/2554, application depuis janvier 2025) impose aux entités financières de l'UE une gestion rigoureuse des risques liés aux prestataires TIC critiques. Inclut l'inventaire détaillé des composants logiciels utilisés — en pratique, SBOM devient attendu.

Obligations sectorielles

• FDA (santé) : depuis octobre 2023, les dispositifs médicaux cyber-sensibles commercialisés aux USA doivent fournir un SBOM.
• Automobile UN-R155 : exige un management de cybersécurité qui inclut de facto un inventaire composants.
• Secteur de la défense : le Department of Defense américain généralise les exigences SBOM via CMMC.

ANSSI et recommandations françaises

L'ANSSI recommande largement les SBOM dans ses guides modernes sur la sécurité du développement et la réponse à incident. Pas d'obligation réglementaire spécifique ANSSI en 2026 — mais les obligations NIS2 et CRA transposées en droit français rendent les SBOM pratiquement incontournables pour les organisations régulées.

05 — OutilsGénération et gestion des SBOM

Génération de SBOM — outils open source

• Syft (Anchore) : référence open source en 2026. Couvre la majorité des écosystèmes (npm, pip, Maven, Cargo, Go, Ruby, etc.), conteneurs, filesystems. Sort SPDX et CycloneDX.
• CycloneDX Tools : suite complète de l'OWASP incluant plugins Maven/Gradle/npm/pip/Cargo/NuGet/Go.
• SBOM Tool (Microsoft) : outil open source Microsoft, génère SPDX.
• SPDX SBOM Generator : outil de la Linux Foundation.
• Trivy (Aqua Security) : scanner polyvalent qui génère également des SBOM.
• Tern : spécialisé conteneurs, VMware origine.

Génération intégrée aux plateformes

• GitHub : génération automatique de SBOM pour les repos, téléchargeable depuis l'onglet Security. Inclus dans les plans gratuits.
• GitLab : Dependency Scanning intégré qui produit des SBOM.
• Azure DevOps : Microsoft SBOM Tool intégré.
• AWS CodeCatalyst : intégration native.

Outils commerciaux DevSecOps intégrant SBOM

• Snyk : plateforme DevSecOps complète avec SBOM natif et analyse de vulnérabilités croisée.
• Sonatype Nexus Lifecycle : historique du marché, gestion avancée de composants open source.
• Mend (ex-WhiteSource) : focus licences et vulnérabilités.
• Checkmarx : intégration SBOM dans sa plateforme AppSec.
• Veracode : SCA intégrant SBOM.
• Black Duck Security Advisor (Synopsys puis Black Duck) : référence historique SCA.
• JFrog Xray : dans l'écosystème JFrog Artifactory.

Gestion et consommation des SBOM

• OWASP Dependency-Track : plateforme open source de référence pour la gestion de SBOM en continu — réception, stockage, analyse de vulnérabilités via NVD/OSS Index, alerting, politiques. Très utilisée.
• GUAC (Graph for Understanding Artifact Composition) : projet récent de la CNCF, agrège SBOM, SLSA, VEX dans un graphe interrogeable.
• Chainguard Enforce : gouvernance de la chaîne d'approvisionnement.

Analyse de SBOM propriétaire et binaires

Quand le code source n'est pas disponible (logiciel commercial, firmware, IoT), des outils spécialisés extraient les SBOM à partir des binaires :

• Binarly : analyse binaire, spécialiste firmware.
• ReversingLabs : analyse composite de fichiers.
• JFrog (acquisition Qwak) : capacités binary SBOM.

Écosystème français et européen

• Sonar (français, siège à Genève) : SonarQube intégrant du SCA.
• Endor Labs, Ox Security : acteurs montants.
• Les MSSP européens (Orange Cyberdefense, Wavestone) proposent des services managés de gouvernance SBOM.

06 — VEXSBOM et VEX, la complémentarité

Le problème de l'inflation d'alertes

Un SBOM révèle souvent plusieurs centaines de vulnérabilités dans les composants d'une application moderne. Beaucoup ne sont pas exploitables dans le contexte spécifique de l'usage : code non atteint, configuration spécifique, mitigation déjà en place. L'équipe applicative se retrouve noyée.

VEX — Vulnerability Exploitability eXchange

Pour répondre à ce problème, le format VEX permet au fournisseur d'un logiciel de déclarer pour chaque vulnérabilité potentiellement affectant ses composants : elle est exploitable ou non dans le produit, avec explication.

Les 4 statuts VEX :

• Not affected : le produit n'est pas vulnérable (ex. code vulnérable non utilisé).
• Affected : le produit est vulnérable.
• Fixed : la vulnérabilité a été corrigée.
• Under investigation : en cours d'analyse.

Formats VEX dominants

• CSAF (Common Security Advisory Framework) 2.0 : format OASIS orienté advisory sécurité, contient un profil VEX.
• CycloneDX VEX : intégré nativement dans les SBOM CycloneDX.
• OpenVEX : format léger développé par la communauté.

Usage combiné SBOM + VEX

1. Le fournisseur publie son SBOM + VEX associé à chaque release.
2. Le client consomme le SBOM pour savoir ce qui est installé, le VEX pour prioriser les remédiations.
3. Quand une nouvelle CVE touche un composant listé, le SBOM identifie immédiatement les produits concernés ; le VEX (s'il est émis par l'éditeur) indique si l'exploitation est possible.
4. La décision (patcher d'urgence, attendre, ignorer) repose sur des données qualifiées plutôt que sur la panique.

Les SBOM sans VEX associés produisent beaucoup de bruit. Les organisations matures intègrent désormais systématiquement les deux dans leurs processus.

07 — DémarcheMettre en place les SBOM en pratique

08 — FAQQuestions fréquentes

Faut-il un SBOM pour une PME ?

Si la PME développe du logiciel vendu à des clients : oui, elle sera progressivement tenue de fournir un SBOM sous CRA d'ici 2027. Même avant obligation, c'est une bonne pratique facilement accessible (GitHub SBOM natif, Syft gratuit). Si la PME n'est que consommatrice de logiciels : pas d'obligation de générer, mais intérêt à exiger des SBOM de ses fournisseurs critiques et à vérifier leur présence lors des achats. Pour la plupart des PME, un SBOM minimum issu de GitHub pour chaque projet et des clauses SBOM dans les contrats fournisseurs critiques constituent un bon point de départ.

Le SBOM remplace-t-il les scans de vulnérabilités ?

Non, les deux sont complémentaires. Le SBOM est l'inventaire (quoi est dans mon système). Le scan est l'analyse (quelles vulnérabilités affectent ces composants). Dependency-Track et équivalents font les deux en combinant le SBOM à des sources de vulnérabilités (NVD, OSS Index). Sans SBOM, le scan est incomplet : il rate les composants non détectés par l'outil. Avec SBOM seul, aucune exploitation des données pour la sécurité.

Comment un SBOM aide-t-il face aux nouvelles CVE ?

Dès qu'une nouvelle CVE est publiée sur un composant (ex. Log4Shell, XZ Utils backdoor), une requête sur le référentiel SBOM centralisé identifie en minutes quelles applications et serveurs contiennent ce composant. Sans SBOM, il faudrait des jours à des semaines d'inventaire manuel. Le ROI principal du SBOM se matérialise justement lors de ces moments de crise. Pour préparer ces situations, faire des exercices simulés régulièrement.

Quelle fréquence de mise à jour d'un SBOM ?

À chaque build. L'objectif est d'avoir toujours un SBOM correspondant exactement à la version déployée. Les pratiques modernes : génération automatique en CI/CD, stockage en regard du binaire dans l'artifactory, conservation de l'historique. Un SBOM n'est pas un document statique mais un artefact produit et versionné comme le code.

Peut-on générer un SBOM pour un logiciel dont on n'a pas le code source ?

Oui, mais plus difficilement. Des outils spécialisés (Binarly, ReversingLabs, Syft pour certains binaires) analysent les exécutables, bibliothèques et conteneurs pour extraire les composants détectés. La précision est généralement inférieure à un SBOM issu du code source : certains composants statiquement liés ou obfusqués peuvent échapper. Pour les produits commerciaux, exiger un SBOM fourni par l'éditeur reste la meilleure approche.