La plupart des équipes avec qui je parle savent générer une SBOM. Beaucoup moins peuvent dire si elle est complète, qui l’a signée, où se trouve la version de l’an dernier, ou ce qui se passe quand une nouvelle CVE correspond à l’un de ses composants. En octobre 2026, l’ENISA a publié le Technical Advisory for Software Bill of Materials, et c’est de cette seconde série de questions qu’il traite. Cet article résume l’avis et y ajoute des remarques tirées de notre propre travail en SCA.
Ce qu’est l’avis, et ce qu’il n’est pas
L’avis est la version finale d’un document qui a commencé comme projet sous le titre “SBOM Landscape Analysis: Towards an implementation guide”. L’ENISA a soumis ce projet à consultation entre le 17 décembre 2025 et le 23 janvier 2026 et a reçu 67 contributions. Elle s’est aussi appuyée sur son enquête SBOM Adoption State of Play 2026, publiée en juin 2026, et sur une revue par le volet SBOM du groupe d’experts CRA entre le 31 juillet et le 11 septembre 2026. Les retours ont convaincu l’ENISA de transformer le projet en avis technique, le même format que son avis sur l’utilisation sécurisée des gestionnaires de paquets.
Quelques points à connaître avant de le lire :
- Il s’adresse aux organisations qui débutent avec les SBOM, en particulier les PME et les responsables de projets open source. Il ne propose volontairement pas de modèle de maturité.
- C’est un guide. Les recommandations ne sont pas obligatoires, l’ENISA précise que le document n’est pas une interprétation juridique du CRA, et certaines pratiques vont au-delà de ce que le CRA exige.
- Il ne couvre que le logiciel. Les nomenclatures pour l’IA, le matériel et la cryptographie sont hors périmètre.
- Il est publié sous licence CC BY 4.0 et suit les principes du Secure by Design and Default Playbook de l’ENISA.
L’ENISA reprend la définition de la SBOM donnée par le CRA : un registre formel contenant les détails et les relations de chaîne d’approvisionnement des composants inclus dans les éléments logiciels d’un produit comportant des éléments numériques. Elle fait ensuite une remarque à répéter à tous ceux qui traitent la SBOM comme un simple livrable de conformité. Selon l’ENISA, les SBOM sont une couche de données fondamentale, pas une solution de sécurité complète. Leur valeur vient de ce que vous en faites : correctifs, décisions documentées sur les vulnérabilités, contrôles de licences et achats.
L’écart entre ce dont les acheteurs ont besoin et ce qu’ils reçoivent
L’avis cite l’enquête State of Play tout au long du document, et les chiffres expliquent pourquoi il consacre plus de place au cycle de vie qu’à la génération.
| Profondeur de la SBOM | Organisations qui en ont besoin | Organisations qui la reçoivent |
|---|---|---|
| Tous les composants principaux et les dépendances directes, avec les known unknowns déclarés | 36% | 29% |
| Analyse en profondeur complète | 24% | 14% |
| Analyse en profondeur incluant les known unknowns déclarés | 27% | 12% |
Un “known unknown” est un composant dont les dépendances n’ont pas pu être déterminées, déclaré comme tel dans la SBOM au lieu d’être omis en silence. Les acheteurs veulent savoir où se trouvent les angles morts.
L’automatisation raconte la même histoire. 41% des répondants visent une génération de SBOM entièrement automatisée pour chaque build ou release, mais seulement 26% prévoient d’automatiser entièrement les mises à jour de la SBOM pendant toute la période d’assistance, et environ 23% prévoient de le faire en partie. Générer une SBOM est un problème largement résolu. La garder exacte tant que le produit est maintenu ne l’est pas.
Ce que contient une SBOM
L’ENISA ne définit pas sa propre liste de champs. Elle met en correspondance les deux références que la plupart des organisations rencontreront : la TR-03183-2 du BSI allemand (version 2.1.0) et les 2026 Minimum Elements for a Software Bill of Materials de la CISA, publiés à l’été 2026 comme guide commun avec la NSA, le FBI et des agences partenaires d’autres pays.
Le socle est le même dans les deux : qui a créé la SBOM et quand, et pour chaque composant son créateur, son nom, sa version, ses identifiants, son empreinte, sa licence et ses dépendances. Les différences sont dans les détails.
| Uniquement dans la BSI TR-03183-2 | Uniquement dans les minimum elements 2026 de la CISA |
|---|---|
| URI de la SBOM | Version de la SBOM |
| URI distinctes pour le code source d'un composant et sa forme déployable | Nom et version du format de données de la SBOM |
| Empreinte du code source du composant (facultatif) | Signature de l'auteur de la SBOM |
| Licences de distribution, d'origine et effective dans des champs distincts | Nom et version de l'outil qui a généré la SBOM |
| Propriétés d'exécutable, d'archive et de données structurées | Contexte de génération : avant, pendant ou après le build |
| URL du security.txt du créateur du composant (facultatif) | Algorithme d'empreinte |
Le BSI demande aussi une adresse e-mail pour le créateur de la SBOM et pour chaque créateur de composant, ou une URL à défaut d’adresse e-mail. La CISA demande un nom.
Si vous livrez des clients en Allemagne et aux États-Unis, générez l’union des deux listes. Le nom et la version de l’outil, le format et l’horodatage sont fournis par tout générateur correct. Les propriétés propres au BSI, la licence effective et la signature demandent des étapes supplémentaires dans votre pipeline.
Formats et types
73% des organisations de l’enquête utilisent CycloneDX ou SPDX, et l’avis compare les versions actuelles des deux.
| SPDX 3.0.1 | CycloneDX 1.7 | |
|---|---|---|
| Normalisation | SPDX 2.2.1 est la norme ISO/IEC 5962:2021, SPDX 3.0 est une norme OMG, et SPDX 3 est en cours à l'ISO | Ratifié sous le nom ECMA-424, maintenu par l'Ecma TC54, et en procédure accélérée à l'ISO/IEC JTC 1 |
| Orientation | Métadonnées détaillées des composants pour les licences, la provenance et l'analyse de risque sur plusieurs gammes de produits | Usages de sécurité : suivi des vulnérabilités avec VEX natif, services et API, intégrité cryptographique |
Pour le CRA, les deux conviennent. Choisissez le format que lisent vos clients et vos outils. OWASP Dependency-Track, par exemple, n’ingère que du CycloneDX. Si vous avez besoin des deux, Protobom de l’OpenSSF convertit de l’un à l’autre.
Le format n’est que la moitié de l’histoire. Le moment où vous générez la SBOM détermine ce qu’elle contient. L’ENISA reprend les six types de SBOM de la CISA :
| Type | Généré à partir de | Usage typique |
|---|---|---|
| Design | La conception prévue, y compris des composants qui n'existent peut-être pas encore | Décisions d'architecture, achats de licences, modélisation des menaces |
| Source | L'environnement de développement, les fichiers source et les dépendances déclarées | Visibilité sur les dépendances, détection précoce des vulnérabilités |
| Build | Le processus de build : fichiers source, dépendances résolues, composants construits et données de build | Conformité réglementaire, évaluation des vulnérabilités, transparence |
| Analyzed | L'analyse d'artefacts finis comme les exécutables, paquets, conteneurs et images de VM, généralement par heuristiques ; parfois appelée SBOM tierce | Conformité des licences, vérification de la provenance, risque de chaîne d'approvisionnement |
| Deployed | Les logiciels présents sur un système, en combinant des SBOM avec l'analyse de la configuration | Inventaire des actifs, gestion des correctifs, gestion de configuration |
| Runtime | L'instrumentation du système en cours d'exécution, y compris les bibliothèques chargées dynamiquement, les plug-ins et les agents injectés | Détection des menaces, évaluation de la surface d'attaque, surveillance à l'exécution |
Le nouveau champ de contexte de génération de la CISA existe pour qu’un consommateur sache quel type il a sous les yeux. Pour une mise en œuvre minimale viable, l’ENISA est claire : commencez par la SBOM de build, car c’est le moment où les dépendances sont connues avec le plus de précision.
Le cycle de vie de la SBOM
L’avis décrit la SBOM comme un cycle de vie en sept phases, bâti sur quatre principes : continue, digne de confiance, exploitable et à jour.
- Build
- Génération
- Validation
- Signature
- Stockage
- Consommation
- Maintenance et mise à jour
Il transforme ensuite ce cycle de vie en architecture de référence pour un pipeline CI/CD. Chaque phase est une barrière. Si elle échoue, le pipeline s’arrête et déclenche une alerte.
- La génération détecte les composants et leurs dépendances directes et transitives, capture des métadonnées comme les versions, les licences et les PURL, construit le graphe de dépendances, normalise les noms de paquets et les formats de version, et écrit du SPDX ou du CycloneDX.
- La validation contrôle le schéma, les métadonnées, la cohérence des identifiants et des références de dépendances, éventuellement un profil comme les champs obligatoires du BSI, et la correspondance entre la SBOM et l’artefact. L’ENISA insiste sur les identifiants de composants comme élément à valider absolument.
- La signature canonicalise la SBOM, calcule une empreinte SHA-256, la signe, lie la signature à une identité via un certificat X.509 ou Sigstore, et ajoute un horodatage.
- Le stockage place la SBOM signée dans un dépôt immuable, versionné et à accès contrôlé, avec preuve d’intégrité, sauvegardes et politique de conservation.
- La consommation alimente la gestion des vulnérabilités, la conformité des licences, la gestion du risque fournisseur, la gouvernance open source, la conformité réglementaire et la gestion des actifs logiciels.
- La maintenance régénère la SBOM à chaque changement : nouveau build ou nouvelle release, mises à jour de dépendances, correctifs de sécurité, mises à jour de paquets système, bibliothèques ajoutées ou retirées, ou modification de la configuration de build.
Parmi les consommateurs du schéma de cycle de vie figurent les autorités de surveillance du marché, à côté des équipes sécurité, développement et conformité, des fournisseurs et des clients. Avec le CRA, une autorité peut demander votre SBOM, et vous voudrez alors remettre celle qui correspond exactement à la version de produit concernée.
Des outils pour chaque phase
L’avis associe des outils open source aux phases du cycle de vie. Une organisation sur trois dans l’enquête s’appuie sur des outils open source, et l’ENISA présente la liste comme indicative et non exhaustive.
| Phase | CycloneDX | SPDX |
|---|---|---|
| Génération | cyclonedx-maven-plugin, @cyclonedx/cyclonedx-npm, cyclonedx-gomod, CycloneDX .NET tool, cdxgen, Syft, SBOMit | spdx-gradle-plugin, spdx-maven-plugin, outils SPDX pour Python, Java et Go, Yocto, Linux (make spdx), Zephyr (west spdx), kubernetes-sigs/bom, GitHub SBOM, Microsoft sbom-tool, Syft, Trivy, ORT, SBOMit |
| Validation du schéma | CycloneDX CLI | Validateur en ligne SPDX et NTIA checker |
| Score de qualité | sbomqs, sbom-scorecard | |
| Signature | Attestations GitHub CLI, Cosign avec signature sans clé via Sigstore | |
| Stockage | Artefacts de workflow GitHub Actions (actions/upload-artifact) | |
| Consommation | Grype, Trivy, OWASP Dependency-Check, OWASP Dependency-Track, GitHub Dependency Review, OWASP dep-scan, OSV-Scanner, CVE Binary Tool | Fossology, sbomify, sbom-cve-check, SPDX 3 visualizer, GitHub Dependency Review |
Deux entrées appellent une réserve. OWASP Dependency-Check analyse directement les fichiers du projet et les dépendances, et n’est pas conçu pour ingérer des SBOM. L’outil OWASP qui lit et surveille les SBOM est Dependency-Track, et notre guide de déploiement de Dependency-Track montre comment le faire tourner sur votre propre infrastructure.
Les artefacts de workflow expirent en outre après leur durée de conservation, ce qui ne colle pas avec le conseil de l’avis lui-même sur le stockage immuable et la conservation. Le CRA attend que vous conserviez la documentation technique au moins dix ans après la mise sur le marché du produit, ou pendant la période d’assistance si elle est plus longue. Stockez les SBOM dans un dépôt d’artefacts que vous maîtrisez.
Un modèle de menaces pour le pipeline SBOM
L’avis comprend un modèle de menaces STRIDE. Il couvre tout l’écosystème SBOM, pas seulement le fichier : les générateurs, les services de validation et de signature, les dépôts et les pipelines qui consomment les SBOM.
| STRIDE | Exemples de menaces | Mesures indicatives |
|---|---|---|
| Spoofing | Un auteur de SBOM usurpé, un faux consommateur qui demande une SBOM restreinte, un pipeline CI/CD ou un outil de génération usurpé, des certificats de signature volés, un miroir de dépôt compromis | Signatures numériques, vérification de l'identité du fournisseur et du consommateur, attestations de build, pipelines authentifiés, gestion des clés, révocation des certificats |
| Tampering | Composants, versions ou dépendances modifiés après la génération ; métadonnées modifiées avant la génération ; empreintes, provenance, PURL ou CPE altérées | Vérification de l'intégrité et des signatures, attestations signées, vérification des références externes |
| Repudiation | Un producteur nie avoir généré, publié ou diffusé une SBOM | Signatures, horodatages, journaux d'audit et de dépôt, releases signées |
| Information disclosure | La SBOM révèle la pile technologique, des composants propriétaires, des relations fournisseurs, le graphe de dépendances, les versions exactes, ou des certificats et processus de release internes | Partage contrôlé, contrôle d'accès, journalisation d'audit |
| Denial of service | Un dépôt indisponible, des SBOM très volumineuses ou profondément imbriquées qui épuisent les parseurs, un volume de SBOM qui remplit le stockage et bloque les pipelines | Redondance et protection DDoS, limites de taille, durcissement des parseurs, politique de conservation |
| Elevation of privilege | Élévation de privilèges dans le pipeline de build, le dépôt de SBOM ou l'infrastructure de signature | Contrôle d'accès, durcissement du pipeline, gestion des clés |
Deux lignes méritent plus d’attention qu’elles n’en reçoivent d’habitude. La divulgation d’informations explique pourquoi le CRA vous permet de garder la SBOM dans votre documentation technique au lieu de la publier : une liste de versions exactes est une liste de CVE à essayer. Décidez client par client ce que vous partagez et à quelles conditions. Et le déni de service sur les parseurs devient réel dès que vous acceptez des SBOM de fournisseurs. Traitez-les comme des entrées non fiables.
Servez-vous du tableau comme d’un point de départ, pas comme de votre modèle de menaces. Votre pipeline a ses propres frontières de confiance, et les questions qui les révèlent sont les mêmes que pour tout autre système. Le Secure by Design and Default Playbook propose une méthode légère si votre équipe n’a jamais modélisé les menaces de son système de build.
Dix risques qui rendent les SBOM moins utiles
À côté des menaces, l’avis énumère des risques généraux qui nuisent à l’exactitude, à l’intégrité ou à l’utilisation des SBOM.
| Risque | À quoi il ressemble | Mesure indicative |
|---|---|---|
| Format non standard | Un format propriétaire ou maison | Utiliser SPDX ou CycloneDX |
| Non lisible par machine | Un PDF ou un tableur destiné à des humains | Un format lisible par machine adapté au traitement automatisé |
| SBOM incomplète | Des composants ou dépendances manquent | Génération automatique à la release, intégration CI/CD, known unknowns et métadonnées manquantes documentés |
| SBOM obsolète | La SBOM ne correspond plus au logiciel | Régénérer aux déclencheurs de maintenance |
| Mauvaise identification des composants | Les composants ne peuvent pas être rapprochés d'un écosystème à l'autre | L'URL du dépôt amont, ou une PURL avec espace de noms, version exacte et empreintes, ou une CPE appliquée de façon cohérente avec version exacte et empreintes |
| Exactitude insuffisante | Les heuristiques ajoutent des composants absents, en oublient de présents ou indiquent de mauvaises versions | Choisir la technique de génération par écosystème et type d'artefact, valider les SBOM par rapport aux artefacts, contrôler la complétude et les identifiants |
| Lien faible entre SBOM et artefact | On ne sait pas quel build, quelle image ou quel paquet la SBOM décrit | Lier la SBOM à l'artefact par une empreinte ou un digest immuable et vérifier l'association |
| Exploitation limitée | Les SBOM sont générées mais jamais utilisées | Les consommer pour la gestion des actifs, des vulnérabilités et des licences |
| Conservation insuffisante | Les anciennes SBOM, signatures et documents VEX ont disparu | Une politique de conservation, des SBOM par release, un historique des versions, une traçabilité SBOM-artefact, des procédures de destruction |
| Pas de priorisation des vulnérabilités | Chaque résultat est traité comme également urgent | Combiner les données SBOM avec VEX, la criticité des actifs et l'exposition dans un processus fondé sur le risque |
La mauvaise identification des composants est celui que je rencontre le plus. Pour le C et le C++, c’est l’état par défaut : les générateurs ajoutent au mieux une PURL, alors que la NVD enregistre les vulnérabilités de bibliothèques comme OpenSSL et zlib sous des CPE. La mesure de l’ENISA, une CPE appliquée de façon cohérente avec la version exacte, est l’approche de notre article sur l’enrichissement CPE des bibliothèques C++ dans les builds Conan.
La conservation est celui que les équipes découvrent trop tard. Quand une CVE sort pour une bibliothèque, la question n’est pas seulement de savoir si le build du jour est touché, mais quelles versions livrées le sont. Vous ne pouvez y répondre qu’avec les SBOM de ces versions. Pour la priorisation, l’étape d’atténuation de notre article sur les gestionnaires de paquets montre comment EPSS, le catalogue KEV, VEX et l’atteignabilité s’articulent.
Par où commencer : l’intégration au build
Le conseil de l’ENISA pour une mise en œuvre minimale viable est de commencer au moment du build et d’utiliser l’infrastructure CI existante. Il se décompose en six étapes :
- Identifier les points d’intégration dans le pipeline actuel, comme après la compilation, avant l’empaquetage et lors de la préparation de la release.
- Configurer la génération : format, niveau de détail, périmètre des composants, profondeur de parcours des dépendances, et variables d’environnement pour des exécutions cohérentes.
- Ajouter une étape de pipeline dédiée qui s’exécute après les tâches de build dont elle dépend, avec une gestion des échecs qui évite qu’une génération incomplète de SBOM bloque les chemins critiques.
- Définir les déclencheurs, par exemple les fusions vers main, les releases taguées et les exécutions de référence planifiées, et ignorer les changements qui ne touchent que la documentation.
- Stocker les SBOM près des artefacts de build, avec un versionnement aligné sur vos versions logicielles et une conservation alignée sur le cycle de vie des artefacts.
- Valider le format, vérifier que les champs obligatoires sont remplis, et vérifier les signatures là où vous utilisez des attestations.
L’étape 3 cadre mal avec l’architecture de référence, où chaque phase en échec arrête le pipeline. Les deux se défendent, alors décidez à l’avance quels échecs liés à la SBOM bloquent une release et lesquels déclenchent seulement une alerte. Une SBOM manquante pour une release candidate doit bloquer. Un score de qualité instable, sans doute pas.
L’avis décrit deux modèles d’intégration. L’intégration au build génère la SBOM juste après une compilation réussie, tant que le contexte de build est encore disponible. Des systèmes de build comme Yocto, Kubernetes, Linux et Zephyr intègrent déjà la génération de SBOM, il suffit de l’activer. La génération déclenchée par événement utilise les webhooks du dépôt sur les commits, les pull requests et les releases, avec une file d’attente pour les demandes simultanées et un historique de génération pour les audits.
Les conseils de configuration communs sont concrets : un répertoire dédié aux SBOM, les SBOM source séparées des SBOM générées, des conventions de nommage qui relient chaque SBOM à son composant, des motifs d’exclusion pour que les SBOM ne se retrouvent pas dans les builds, des modèles de pipeline réutilisables, et des points de validation avant toute publication. Les vulnérabilités trouvées grâce à la SBOM doivent être reliées à des délais de correction, des seuils de gravité et des circuits d’escalade, avec des délais fondés sur la gravité, l’exploitabilité, l’exposition, la criticité du produit, la disponibilité des correctifs et les mesures compensatoires.
Deux dernières recommandations ressortent. Les processus SBOM doivent produire des preuves pour les audits internes, les évaluations de la conformité, la réponse aux incidents et les demandes des autorités de contrôle : journaux de génération, résultats de validation, signatures, horodatages, liens avec les releases et registres de conservation. Et les organisations doivent documenter les lacunes connues, les exceptions et les known unknowns de leur couverture SBOM, surtout là où des dépendances ne peuvent pas être identifiées, où des informations fournisseur manquent ou où des composants uniquement binaires ne peuvent pas être entièrement analysés.
Mesures de sécurité pour le pipeline
L’avis se termine par des mesures de sécurité sur l’ensemble du pipeline SBOM. Pour toutes les phases, il cite le contrôle d’accès fondé sur les rôles, la MFA, le moindre privilège, TLS 1.3 avec validation des certificats, la journalisation d’audit, des alertes sur les validations et signatures en échec, la revue de code et la protection des branches pour les définitions de pipeline, une configuration sous contrôle de version, et la vérification de l’intégrité des générateurs et autres outils avant leur exécution. La génération y ajoute des registres de confiance et une provenance de build vérifiable. La signature et le stockage ajoutent des secrets dans un coffre, un lien cryptographique entre SBOM et artefact, un stockage inviolable, une surveillance de l’intégrité, un historique des versions, ainsi que la sauvegarde et la restauration des dépôts, du matériel de signature et des journaux d’audit.
Rien de tout cela n’est propre aux SBOM. C’est le durcissement dont votre système de build a besoin de toute façon. Une SBOM n’est fiable que si le pipeline qui l’a produite l’est.
Ce que cela signifie pour le CRA
L’annexe I, partie II, du Cyber Resilience Act impose aux fabricants de recenser et de documenter les vulnérabilités et les composants des produits comportant des éléments numériques, notamment en établissant une nomenclature des logiciels dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau des produits. L’article 13, paragraphe 5, ajoute un devoir de diligence pour les composants tiers, open source compris. La SBOM fait partie de la documentation technique, qu’une autorité de surveillance du marché peut demander (annexe VII, point 8). L’article 13, paragraphe 24, permet à la Commission de préciser le format et les éléments de la SBOM par un acte d’exécution. L’obligation s’applique à partir du 11 décembre 2027, avec le reste de l’annexe I.
L’avis n’interprète pas ces obligations, mais il en précise largement le comment. Deux enseignements à en tirer. Le minimum légal porte sur les dépendances de premier niveau, alors que l’enquête montre que les acheteurs demandent de la profondeur : vos clients placeront la barre plus haut que le règlement. Et presque chaque recommandation produit des preuves : journaux, résultats de validation, signatures, registres de conservation. C’est exactement ce que demandera un organisme d’évaluation de la conformité ou une autorité.
Côté normes, l’EN 40000-1-3 couvre les exigences de gestion des vulnérabilités de l’annexe I, partie II, où se trouve l’obligation de SBOM. Notre panorama des normes harmonisées suit son avancement, et notre guide CRA pour les PME couvre les autres obligations.
Notre avis
C’est le document SBOM le plus pratique publié jusqu’ici par un organisme de l’UE. La correspondance entre BSI et CISA épargne une journée de tableur à quiconque sert les deux marchés, l’architecture de référence CI/CD donne aux équipes une cible concrète, et le modèle STRIDE traite le pipeline SBOM comme une surface d’attaque, ce que la plupart des organisations ne font toujours pas.
Il a des lacunes. Il est écrit du point de vue du producteur : le contrôle de la qualité des SBOM reçues des fournisseurs, et la conduite à tenir quand elles sont insuffisantes, reçoivent peu d’attention, alors que c’est là que beaucoup de PME passeront leur temps quand les fournisseurs commenceront à livrer des SBOM CRA. VEX apparaît dans le tableau des risques, mais pas dans le cycle de vie ni dans le pipeline. Et le tableau des outils mérite une vérification avant d’être repris.
Si vous partez de zéro, suivez l’ordre de l’avis. Générez une SBOM CycloneDX ou SPDX au moment du build dans votre CI, validez le schéma et les identifiants de composants, signez-la, stockez-la dans un endroit que vous maîtrisez, et surveillez-la en continu avec un outil comme Dependency-Track. Faites fonctionner cela pour un produit avant de penser aux SBOM d’exécution.
Sources : ENISA, Technical Advisory for Software Bill of Materials, octobre 2026 ; ENISA, SBOM Adoption State of Play 2026 ; BSI TR-03183-2, version 2.1.0 ; CISA, 2026 Minimum Elements for a Software Bill of Materials ; Règlement (UE) 2024/2847, le Cyber Resilience Act.