Vérification pratique de la SBOM : comment mettre en œuvre la nomenclature logicielle d’ici septembre 2026

12 min de lecture

500.000 listes de composants logiciels sont gérées par la Deutsche Bahn. Ce qui peut sembler bureaucratique deviendra obligatoire pour tous les fabricants de produits numériques dans l’UE à partir de septembre 2026. Ceux qui ne se préparent pas risquent des amendes allant jusqu’à 15 millions d’euros — et l’exclusion du marché européen.

L’essentiel en bref

• 🔒 L’EU Cyber Resilience Act rendra les listes de composants logiciels (SBOMs) obligatoires à partir de décembre 2027. Les premières obligations de déclaration entreront en vigueur en septembre 2026 (Règlement UE 2024/2847).
• 📊 75 % de toutes les entreprises ont été victimes d’une attaque de la chaîne d’approvisionnement en 2024. La prévision de Gartner de 45 % était trop conservatrice (BlackBerry, 2024).
• 🛡️ Le BSI exige dans TR-03183-2 spécifiquement CycloneDX à partir de 1.6 ou SPDX à partir de 3.0.1 comme format SBOM (BSI, 2024).
• 🏭 La Deutsche Bahn gère 500.000 listes de composants avec des outils open-source et sa propre logique (FOSDEM 2026).
• ⚙️ Trois voies de mise en œuvre : entièrement automatique dans la pipeline CI/CD, hybride avec revue, ou manuelle pour les logiciels hérités.

Septembre 2026 : le compte à rebours est lancé

Votre équipe de sécurité est confrontée à un problème concret : à partir du 11 septembre 2026, tous les fabricants de produits avec des éléments numériques doivent déclarer les vulnérabilités activement exploitées à l’ENISA dans les 24 heures. Sans une liste de composants logiciels à jour, cela est tout simplement impossible. En effet, celui qui ne sait pas quels composants sont intégrés dans son logiciel ne peut pas évaluer si une nouvelle vulnérabilité affecte son produit.

Le temps moyen de détection des infiltrations dans la chaîne d’approvisionnement est actuellement de 287 jours. Près de dix mois pendant lesquels les attaquants opèrent sans être détectés dans des systèmes compromis. Une SBOM réduit considérablement cette période en permettant une consultation immédiate : utilisons-nous la bibliothèque affectée ? Dans quelle version ? Dans quel produit ?

Ce qu’est une SBOM — et ce qu’elle n’est pas

Une Software Bill of Materials documente tous les composants, bibliothèques et dépendances dans un produit logiciel. Comparable à la liste des ingrédients sur un emballage alimentaire, mais pour le code. Le CRA la définit comme un « enregistrement formel contenant les détails et les relations de la chaîne d’approvisionnement des composants contenus dans les éléments logiciels ».

Important : une SBOM n’est pas un audit de sécurité. Elle rend transparent ce qui a été intégré — pas si c’est sûr. Mais sans cette transparence, une évaluation systématique des vulnérabilités n’est pas possible. C’est seulement la combinaison de la SBOM et du VEX (Vulnerability Exploitability eXchange) qui donne une image complète : la SBOM liste les composants, le VEX évalue si une vulnérabilité connue est réellement exploitable dans le contexte d’utilisation concret.

Les échéances réglementaires en un coup d’œil

Le Cyber Resilience Act de l’UE échelonne les obligations en deux étapes :

À partir du 11 septembre 2026 : Obligation de déclaration des vulnérabilités activement exploitées à l’ENISA dans les 24 heures. Cela s’applique également aux produits déjà sur le marché. Sans SBOM et suivi automatisé des vulnérabilités, ce délai est pratiquement impossible à respecter.

À partir du 11 décembre 2027 : Obligation complète de SBOM pour tous les produits avec des éléments numériques commercialisés dans l’UE. La liste des composants doit être dans un format lisible par machine et couvrir au moins les dépendances de niveau supérieur. En cas de non-respect, des amendes allant jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial sont prévues.

Parallèlement, le BSI, en tant que future autorité de surveillance du marché, a publié la directive technique TR-03183-2. Elle va au-delà des exigences minimales de l’UE et demande, entre autres, des sommes de contrôle cryptographiques, des identifiants de licence et des mécanismes de signature.

„Le CRA est un véritable changement pour la sécurité des produits numériques !“

– Claudia Plattner, Présidente de l’Office fédéral de la sécurité des technologies de l’information (BSI)

Trois voies vers la SBOM : le test pratique

Pour les responsables informatiques et les CISOs, une question très concrète se pose : comment mettre cela en œuvre ? La réponse dépend de votre propre paysage logiciel, du niveau de maturité de vos pipelines CI/CD et du budget disponible. Trois options se sont établies dans la pratique.

Option 1 : entièrement automatisée dans la pipeline CI/CD

Pour qui : Les entreprises avec des processus de développement modernes, des déploiements basés sur des conteneurs et une culture DevSecOps existante.

Comment cela fonctionne : Des outils comme Syft, Trivy ou cdxgen sont directement intégrés dans la pipeline de construction. À chaque build, une SBOM au format CycloneDX ou SPDX est automatiquement générée, versionnée et stockée de manière centrale. La SBOM se met à jour automatiquement à chaque release.

Pro : Moindre effort opérationnel, haute actualité, évolue avec le nombre de produits. Selon l’ENISA, l’approche recommandée pour les entreprises avec plus de dix produits logiciels.

Contra : Travail d’intégration initial (2-4 semaines par pipeline), nécessite des compétences DevOps, les systèmes hérités sans CI/CD sont laissés de côté.

Option 2 : hybride avec revue manuelle

Pour qui : Les PME avec un paysage logiciel mixte. Certains produits fonctionnent dans des pipelines modernes, d’autres sont des systèmes hérités sans automatisation.

Comment cela fonctionne : Les produits modernes sont capturés automatiquement (comme l’option 1). Pour les logiciels hérités, les SBOM sont générées via des outils d’analyse binaire comme FOSSA ou Mend, qui scannent les binaires finaux. Un analyste de sécurité examine et complète manuellement les résultats.

Pro : Couvre l’ensemble du paysage produit, réalisable de manière réaliste avec les équipes existantes, répond pleinement à la TR-03183-2 du BSI.

Contra : Coûts de personnel opérationnels plus élevés, les étapes manuelles sont sujettes aux erreurs, les cycles de revue ralentissent les releases.

Option 3 : manuelle avec approche par modèles

Pour qui : Les petits éditeurs de logiciels avec peu de produits qui n’ont pas leur propre département DevOps.

Comment cela fonctionne : Les SBOM sont créées manuellement, basées sur les modèles de l’ENISA et les directives du BSI. Les développeurs documentent les bibliothèques et versions utilisées dans un tableau structuré, qui est ensuite converti en CycloneDX ou SPDX.

Pro : Pas d’investissement en outils nécessaire, démarrage rapide possible, répond aux exigences minimales du CRA.

Contra : Ne s’adapte pas, taux d’erreur élevé avec des arborescences de dépendances complexes, devient difficile à gérer avec plus de trois produits. L’ENISA avertit explicitement que les SBOM créées manuellement atteignent rarement la qualité minimale.

Comment la Deutsche Bahn s’y prend

Le fait que les SBOM fonctionnent également à grande échelle est démontré par la Deutsche Bahn. Lors de la FOSDEM 2026, l’entreprise a présenté son approche : 500 000 SBOM, gérés avec une combinaison d’outils open-source et de logique développée en interne, intégrés dans l’architecture d’entreprise existante.

Trois enseignements du projet DB sont également pertinents pour les petites entreprises :

Les SBOM ne sont pas une fin en soi. La DB traite les SBOM comme une méthode de soutien pour divers cas d’utilisation, de la gestion des vulnérabilités à la conformité des licences, en passant par la gestion des fournisseurs. Ceux qui considèrent les SBOM uniquement comme une case à cocher réglementaire perdent l’avantage opérationnel.

L’open source suffit, avec une logique propre. La DB utilise des outils FOSS comme Syft et Trivy, complétés par sa propre logique pour l’intégration dans SAP et les systèmes internes. Les plateformes commerciales coûteuses n’étaient pas nécessaires, mais le travail d’intégration était considérable.

Les personnes font la différence. Les outils techniques seuls ne suffisent pas. La DB souligne que du personnel dédié est nécessaire pour intégrer les SBOM dans les pipelines et surveiller en continu la qualité des listes de pièces générées.

L’envers de la médaille : pourquoi les SBOM ne sont pas une panacée

Malgré l’enthousiasme pour les progrès réglementaires, les SBOM ne résolvent pas tous les problèmes de sécurité de la chaîne d’approvisionnement logicielle. Trois limitations que les responsables informatiques doivent connaître.

Fragmentation des standards. CycloneDX et SPDX sont les deux formats dominants, mais ils ne sont pas entièrement compatibles. De nombreuses entreprises génèrent les deux formats en parallèle : CycloneDX pour l’équipe de sécurité, SPDX pour le département juridique. Cela double l’effort sans gain de sécurité.

Problème de qualité. Toutes les SBOM générées automatiquement n’atteignent pas la qualité minimale. L’ENISA avertit dans son rapport SBOM Landscape (décembre 2025) que les fournisseurs de logiciels n’intègrent souvent pas les données pertinentes, tout simplement parce qu’elles ne sont pas disponibles. Une SBOM qui capture 60 % des dépendances donne une fausse impression de sécurité.

Les attaquants s’adaptent. Les attaques sur la chaîne d’approvisionnement ont doublé en 2025, avec une moyenne de 26 incidents par mois à partir d’avril 2025. Les attaquants ciblent de plus en plus les pipelines de construction eux-mêmes, c’est-à-dire l’infrastructure qui génère les SBOM. Un processus de construction compromis peut produire une SBOM manipulée mais correcte en apparence.

CycloneDX ou SPDX ? La décision du format

Le BSI accepte les deux formats, mais recommande CycloneDX à partir de la version 1.6 ou SPDX à partir de la version 3.0.1. Pour la pratique :

CycloneDX est le meilleur choix pour les équipes de sécurité. Ce format offre un support natif pour VEX, le hachage et les arbres de dépendances. La version 1.7 (octobre 2025) apporte en plus des métadonnées de brevet et une transparence cryptographique étendue. CycloneDX supporte, outre les SBOM logiciels, les listes de matériels (HBOM), d’IA/ML et cryptographiques (CBOM).

SPDX est plus fort dans le domaine de la conformité des licences et de la diligence raisonnable en matière de propriété intellectuelle. En tant que standard certifié ISO/IEC 5962:2021, SPDX bénéficie d’une plus grande acceptation réglementaire, notamment pour les entreprises opérant à l’international.

Recommandation pragmatique : commencez avec CycloneDX pour les opérations de sécurité. Si votre département juridique exige SPDX, utilisez des outils de conversion comme cyclonedx-cli ou spdx-tools. Les deux formats peuvent être convertis l’un dans l’autre, même si des pertes de détails sont possibles.

Check-list : Préparation SBOM en 90 jours

Pour les responsables informatiques qui souhaitent démarrer maintenant, voici le plan concret :

Semaine 1-2 : Inventaire

• Inventorier tous les produits avec des éléments numériques (y compris firmware, logiciels embarqués, appareils IoT)
• Documenter les pipelines CI/CD et les processus de construction existants
• Nommer un responsable (propriétaire SBOM par ligne de produit)

Semaine 3-4 : Projet pilote

• Sélectionner un produit (idéalement avec une pipeline CI/CD moderne)
• Intégrer un générateur de SBOM (Syft pour les conteneurs, cdxgen pour les applications)
• Générer la première SBOM et la valider selon BSI TR-03183-2

Semaine 5-8 : Déploiement

• Transférer le pilote réussi à d’autres produits
• Mettre en place une surveillance des vulnérabilités (OSV, NVD ou flux commercial)
• Définir et tester le processus de notification en 24 heures

Semaine 9-12 : Renforcement

• Définir des métriques de qualité SBOM (taux de couverture, actualité)
• Exiger des SBOM des fournisseurs et les intégrer dans votre propre liste
• Établir un audit trail et une documentation pour la surveillance du marché

L’étape suivante

L’obligation de SBOM arrive. La question n’est pas de savoir si, mais à quel point votre entreprise sera préparée lorsque la première obligation de déclaration entrera en vigueur en septembre 2026. La première étape la plus pragmatique : installez Syft ou Trivy dans un projet de test et générez votre première SBOM. Cela prend 30 minutes et vous montre immédiatement combien de dépendances se cachent dans votre logiciel, dont vous ignoriez l’existence.

Questions fréquentes

Les entreprises qui utilisent uniquement des logiciels (et ne les produisent pas) doivent-elles aussi créer des SBOM ?

Non. Le CRA s’adresse aux fabricants, c’est-à-dire aux entreprises qui mettent des produits avec des éléments numériques sur le marché de l’UE. Les simples utilisateurs n’ont pas besoin de créer leurs propres SBOM, mais devraient exiger des SBOM de leurs fournisseurs. La directive NIS2 exige également que les infrastructures critiques documentent leur chaîne d’approvisionnement logicielle dans le cadre de la gestion des risques.

Quel format de SBOM choisir — CycloneDX ou SPDX ?

Pour la plupart des équipes de sécurité, CycloneDX à partir de la version 1.6 est le choix le plus pragmatique, car il offre une prise en charge native des vulnérabilités et de VEX. SPDX est plus fort en matière de conformité des licences. Le BSI accepte les deux formats dans TR-03183-2. De nombreuses entreprises génèrent les deux en parallèle et les convertissent si nécessaire.

Combien coûte l’introduction de SBOM pour une entreprise de taille moyenne ?

Les coûts des outils peuvent être nuls, car des outils open-source comme Syft et Trivy sont prêts pour la production. Le principal effort réside dans l’intégration : comptez 2 à 4 semaines de travail d’intégration par pipeline CI/CD et un demi ETP pour le monitoring et l’assurance qualité continus. Les plateformes commerciales comme FOSSA ou Mend commencent à environ 15 000 euros par an.

L’obligation de SBOM s’applique-t-elle également aux projets open-source ?

Oui et non. Les logiciels open-source développés comme un projet de loisir sans intention commerciale sont exemptés du CRA. Dès qu’une entreprise intègre des composants open-source dans un produit commercial, elle est responsable de l’obligation de SBOM pour l’ensemble du produit — y compris toutes les dépendances open-source.

La SBOM doit-elle être accessible au public ?

Non. Le CRA précise explicitement que les fabricants ne sont pas obligés de publier leur SBOM. Elle doit faire partie de la documentation technique et être présentée aux autorités de surveillance du marché sur demande. Certaines entreprises publient volontairement leurs SBOM comme signal de confiance envers leurs clients.

Articles complémentaires

• Sécurité de la chaîne d’approvisionnement 2026 : comment les entreprises protègent leur chaîne d’approvisionnement logicielle (SecurityToday)
• NIS2 en Allemagne : ce que les entreprises doivent savoir et mettre en œuvre maintenant (SecurityToday)
• DORA et NIS2 simultanément : double pression de conformité pour les prestataires de services financiers (SecurityToday)

Du réseau MBF-Media

• DORA, AI Act, MiCA simultanément : pourquoi RegTech devient une obligation d’investissement en 2026 (MyBusinessFuture)
• Tendances cloud 2026 : ce que les décideurs IT doivent avoir sur leur radar maintenant (cloudmagazin)
• Due diligence numérique : pourquoi les transactions de fusion-acquisition échouent à cause de l’IT (Digital Chiefs)

Source de l’image de titre : Pexels / cottonbro studio

À propos de l'auteur: Benedikt Langer

Plus d'articles de Benedikt Langer