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

12 min de lecture

La Deutsche Bahn gère à elle seule 500 000 nomenclatures logicielles. Ce qui ressemble à de la bureaucratie deviendra une obligation pour tous les fabricants de produits numériques dans l’UE à partir de septembre 2026. Ceux qui ne s’y préparent pas risquent des amendes pouvant atteindre 15 millions d’euros – et une exclusion du marché européen.

L’essentiel en bref

• 🔒 Le Cyber Resilience Act de l’UE rendra les nomenclatures logicielles (SBOM) obligatoires à partir de décembre 2027. Les premières obligations de déclaration entreront en vigueur dès septembre 2026 (règlement UE 2024/2847).
• 📊 75 % des entreprises ont été victimes d’une attaque sur leur chaîne d’approvisionnement en 2024. La prévision de Gartner, qui tablait sur 45 %, était trop conservatrice (BlackBerry, 2024).
• 🛡️ Le BSI exige dans la TR-03183-2 spécifiquement CycloneDX à partir de la version 1.6 ou SPDX à partir de la version 3.0.1 comme format de SBOM (BSI, 2024).
• 🏭 La Deutsche Bahn gère 500 000 nomenclatures à l’aide d’outils open source et de sa propre logique (FOSDEM 2026).
• ⚙️ Trois approches pour la mise en œuvre : entièrement automatisée dans le pipeline CI/CD, hybride avec revue, ou manuelle pour les logiciels legacy.

Septembre 2026 : le compte à rebours est lancé

Votre équipe sécurité est confrontée à un problème concret : à partir du 11 septembre 2026, tous les fabricants de produits comportant des éléments numériques devront signaler à l’ENISA les vulnérabilités activement exploitées dans un délai de 24 heures. Sans une nomenclature logicielle à jour, cela est tout simplement impossible. Car si l’on ne sait pas quels composants sont intégrés dans son propre logiciel, on ne peut pas évaluer si une nouvelle vulnérabilité affecte son produit.

Le délai 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 en toute discrétion dans les systèmes compromis. Une SBOM réduit considérablement ce délai, car elle permet une vérification immédiate : utilisons-nous la bibliothèque concernée ? Dans quelle version ? Dans quel produit ?

Qu’est-ce qu’une SBOM – et ce qu’elle n’est pas

Une Software Bill of Materials (nomenclature logicielle) documente l’ensemble des composants, bibliothèques et dépendances d’un produit logiciel. À l’image de la liste des ingrédients sur un emballage alimentaire, mais pour le code. Le CRA la définit comme une « enregistrement formel contenant les détails et les relations de la chaîne d’approvisionnement des composants inclus 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écurisé. Mais sans cette transparence, une évaluation systématique des vulnérabilités est impossible. Ce n’est que la combinaison d’une SBOM et d’un VEX (Vulnerability Exploitability eXchange) qui donne une image complète : la SBOM liste les composants, le VEX évalue si une vulnérabilité connue est effectivement exploitable dans le contexte d’utilisation concret.

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

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

À partir du 11 septembre 2026 : Obligation de signaler les vulnérabilités activement exploitées à l’ENISA dans un délai de 24 heures. Cela s’applique également aux produits déjà sur le marché. Sans SBOM et un 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 comportant des éléments numériques commercialisés dans l’UE. La nomenclature doit être disponible dans un format lisible par machine et couvrir au moins les dépendances de premier niveau. En cas de non-respect, des amendes allant jusqu’à 15 millions d’Euro ou 2,5 % du chiffre d’affaires annuel mondial sont encourues.

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

« Le CRA est un gamechanger 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 approches pour la SBOM : le test pratique

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

Option 1 : Intégration entièrement automatisée dans le pipeline CI/CD

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

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

Avantages : Charge de travail continue minimale, actualisation en temps réel, évolutivité avec le nombre de produits. Selon l’ENISA, cette approche est recommandée pour les entreprises disposant de plus de dix produits logiciels.

Inconvénients : Travail d’intégration initial (2 à 4 semaines par pipeline), nécessite des compétences DevOps, les systèmes legacy sans CI/CD restent exclus.

Option 2 : Approche 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 historiques sans automatisation.

Fonctionnement : Les produits modernes sont enregistrés automatiquement (comme dans l’option 1). Pour les logiciels legacy, les SBOM sont générées via des outils d’analyse binaire comme FOSSA ou Mend, qui scannent les binaires finaux. Un analyste en sécurité révise et complète manuellement les résultats.

Avantages : Couvre l’ensemble du portefeuille de produits, réalisable avec les équipes existantes, respecte pleinement la BSI TR-03183-2.

Inconvénients : Coûts de personnel récurrents plus élevés, les étapes manuelles sont sujettes aux erreurs, les cycles de revue ralentissent les releases.

Option 3 : Approche manuelle avec modèle

Pour qui : Les petits éditeurs de logiciels avec peu de produits et sans département DevOps dédié.

Fonctionnement : Les SBOM sont créées manuellement, sur la base des modèles de l’ENISA et des exigences 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.

Avantages : Aucun investissement en outils nécessaire, mise en œuvre rapide possible, respecte les exigences minimales du CRA.

Inconvénients : Ne passe pas à l’échelle, taux d’erreur élevé pour les arbres de dépendances complexes, devient ingérable au-delà de trois produits. L’ENISA met en garde contre le fait que les SBOM créées manuellement n’atteignent souvent pas la qualité minimale requise.

Comment la Deutsche Bahn s’y prend

Que les SBOM fonctionnent aussi à grande échelle, c’est ce que démontre la Deutsche Bahn. Lors de la FOSDEM 2026, l’entreprise a présenté son approche : 500 000 SBOM, gérés grâce à une combinaison d’outils open source et d’une logique développée en interne, intégrée à 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 considère les SBOM comme une méthode d’appui pour divers cas d’usage – de la gestion des vulnérabilités à la conformité des licences, en passant par le contrôle des fournisseurs. Ceux qui ne voient les SBOM que comme une case à cocher réglementaire passent à côté de leur utilité opérationnelle.

L’open source suffit – avec une logique propre. La DB mise sur 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. Des plateformes commerciales coûteuses n’étaient pas nécessaires, mais le travail d’intégration a été considérable.

Ce sont les hommes qui font la différence. Les outils techniques seuls ne suffisent pas. La DB souligne qu’un personnel dédié est indispensable pour intégrer les SBOM dans les pipelines et surveiller en continu la qualité des nomenclatures générées.

Le revers de la médaille : pourquoi les SBOM ne sont pas une solution miracle

Malgré l’enthousiasme suscité par les avancées réglementaires : les SBOM ne résolvent pas tous les problèmes de sécurité de la chaîne d’approvisionnement logicielle. Trois limites doivent être connues des responsables informatiques.

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 sécurité, SPDX pour le service 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 met en garde, dans son rapport SBOM Landscape Report (décembre 2025), que les fournisseurs de logiciels omettent souvent d’inclure des données pertinentes, simplement parce qu’elles ne sont pas disponibles. Une SBOM qui ne couvre que 60 % des dépendances donne un faux sentiment de sécurité.

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

CycloneDX ou SPDX ? Le choix 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, voici ce qu’il en est :

CycloneDX est le meilleur choix pour les équipes sécurité. Le 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 sur les brevets et une transparence cryptographique étendue. CycloneDX prend en charge, outre les SBOM logicielles, les nomenclatures matérielles (HBOM), les listes pour l’IA/ML et les nomenclatures cryptographiques (CBOM).

SPDX est plus adapté au domaine de la conformité des licences et de la due diligence 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, en particulier auprès des entreprises ayant une activité internationale.

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

Checklist : SBOM-Readiness en 90 jours

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

Semaines 1-2 : État des lieux

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

Semaines 3-4 : Projet pilote

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

Semaines 5-8 : Déploiement

• Étendre 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 déclaration sous 24 heures

Semaines 9-12 : Renforcement

• Définir des métriques de qualité des SBOM (degré de couverture, actualité)
• Exiger les SBOM des fournisseurs et les intégrer à votre propre nomenclature
• Constituer une piste d’audit et une documentation pour la surveillance du marché

La prochaine étape

L’obligation de fournir une SBOM arrive. La question n’est pas de savoir si, mais à quel point votre entreprise est 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 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 simplement des logiciels (sans les produire) doivent-elles aussi créer des SBOM ?

Non. Le CRA s’adresse aux fabricants, c’est-à-dire aux entreprises qui mettent à disposition sur le marché de l’UE des produits comportant des éléments numériques. Les simples utilisateurs n’ont pas à créer leurs propres SBOM, mais devraient exiger des SBOM de leurs fournisseurs. La directive NIS2 exige par ailleurs 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 constitue l’entrée la plus pragmatique, car il offre un support natif des vulnérabilités et de VEX. SPDX est plus performant en matière de conformité des licences. Le BSI accepte les deux formats dans la TR-03183-2. De nombreuses entreprises génèrent les deux en parallèle et les convertissent si nécessaire.

Quel est le coût de l’introduction d’une SBOM pour une PME ?

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

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

Cela dépend. Les logiciels open source développés en tant que projets hobby 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 soumise à 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 expressément que les fabricants ne sont pas tenus de publier leur SBOM. Elle doit faire partie de la documentation technique et pouvoir être présentée sur demande aux autorités de surveillance du marché. Certaines entreprises publient volontairement leurs SBOM en guise de signal de confiance envers leurs clients.

Articles complémentaires

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

Issus du réseau média MBF

• DORA, AI Act, MiCA simultanément : pourquoi RegTech devient un investissement obligatoire en 2026 (MyBusinessFuture)
• Tendances cloud 2026 : ce que les décideurs IT doivent avoir à l’œil dès maintenant (cloudmagazin)
• Due diligence numérique : pourquoi les opérations de fusion-acquisition échouent à cause de l’IT (Digital Chiefs)

Source image de titre : Pexels / cottonbro studio

À propos de l'auteur: Benedikt Langer

Plus d'articles de Benedikt Langer