Depuis l’entrée en vigueur du Cyber Resilience Act en décembre 2024, les fabricants de produits numériques ont une obligation nouvelle : savoir exactement ce que contient leur produit. Pas dans les grandes lignes — composant par composant, version par version. C’est ce qu’on appelle un SBOM, et c’est désormais une obligation réglementaire en Europe.

1. Qu’est-ce qu’un SBOM et pourquoi le CRA l’impose

Un SBOM — Software Bill of Materials — est un inventaire structuré de tous les composants qui constituent un logiciel : bibliothèques, dépendances, frameworks, composants tiers et open source, avec leurs versions exactes et leurs licences. C’est, littéralement, la liste des ingrédients de votre produit.

L’article 13 du CRA impose aux fabricants de « identifier et documenter les composants inclus dans les produits comportant des éléments numériques ». En pratique, l’ENISA et la Commission européenne ont confirmé que cette obligation correspond à la production et au maintien d’un SBOM.

La raison est simple : sans inventaire précis, il est impossible de savoir en quelques heures si une nouvelle CVE publiée affecte vos produits. Or le CRA impose une notification à l’ENISA dans les 24h en cas de vulnérabilité activement exploitée. Sans SBOM automatisé, ce délai est impossible à tenir.

2. Ce que le CRA exige exactement

Le texte du CRA ne prescrit pas de format spécifique pour le SBOM. Il impose en revanche plusieurs exigences de fond :

• L’inventaire doit couvrir tous les composants — y compris les dépendances transitives (les dépendances de vos dépendances)
• Il doit être maintenu à jour — un SBOM statique produit lors du lancement n’est pas conforme
• Il doit être accessible sur demande aux autorités de surveillance de marché
• Il doit être versionnés — chaque build de votre produit doit avoir son SBOM correspondant

3. Les formats SBOM reconnus

Deux formats sont devenus les standards de facto pour les SBOM conformes CRA :

CycloneDX

Développé par l’OWASP, CycloneDX est le format recommandé par la Commission européenne dans ses lignes directrices CRA. Il supporte JSON et XML, couvre les composants logiciels, matériels et services, et intègre nativement les métadonnées de vulnérabilités (VEX). C’est le format le plus adopté dans l’écosystème cybersécurité européen.

SPDX

Développé par la Linux Foundation et normalisé ISO (ISO 5962:2021), SPDX est orienté gestion des licences et traçabilité open source. Il est très utilisé dans les environnements Linux et les projets open source. Il supporte JSON, YAML, RDF et un format texte propriétaire.

4. Les outils pour générer un SBOM

La génération manuelle d’un SBOM est trop lente et trop sujette aux erreurs pour être viable sur la durée. Voici les approches recommandées :

Outils open source

• Syft (Anchore) — génère des SBOM CycloneDX et SPDX à partir d’images conteneurs, de répertoires de code et de systèmes de fichiers. Simple à intégrer dans un pipeline CI/CD.
• CycloneDX CLI — outil officiel de l’OWASP, supporte de nombreux gestionnaires de packages (npm, Maven, Gradle, pip, NuGet…).
• SPDX Tools — boîte à outils officielle de la Linux Foundation pour créer, valider et convertir des SBOM au format SPDX.
• Trivy (Aqua Security) — scanner de vulnérabilités qui génère aussi des SBOM, utile pour combiner génération SBOM et analyse de sécurité.

Intégration dans le pipeline CI/CD

L’objectif est d’automatiser la génération à chaque build. Un SBOM doit être produit automatiquement à chaque nouvelle version de votre produit, sans action manuelle. Voici un exemple de workflow GitHub Actions :

5. De la génération à la conformité CRA

Produire un SBOM est la première étape. Pour être conforme CRA, il faut aussi mettre en place le processus aval :

• Corrélation CVE — le SBOM doit être corrélé en continu avec les bases de vulnérabilités (NVD, OSV, VulnDB) pour alerter dès qu’un composant est affecté
• Génération de VEX — pour chaque CVE affectant un composant, vous devez pouvoir produire un VEX indiquant si votre produit est réellement exposé
• Versioning — chaque version de votre produit doit avoir son SBOM associé, stocké et accessible
• Mise à disposition — le SBOM doit être accessible aux autorités sur demande et, selon votre marché, potentiellement partageable avec vos clients

6. Par où commencer si vous partez de zéro

Une mise en conformité SBOM réaliste se déroule en quatre phases :

• Phase 1 — Inventaire manuel initial (semaines 1-2) : listez vos produits concernés et leurs technologies. Identifiez les gestionnaires de packages utilisés (npm, Maven, pip, etc.). C’est la base pour choisir vos outils.
• Phase 2 — Premier SBOM automatisé (semaines 3-4) : intégrez Syft ou CycloneDX CLI sur un produit pilote. Validez la complétude (dépendances transitives incluses). Corrigez les faux positifs.
• Phase 3 — Intégration CI/CD (mois 2) : automatisez la génération à chaque build. Mettez en place le stockage versionné. Connectez à une base de vulnérabilités pour les alertes.
• Phase 4 — Déploiement sur tous les produits (mois 3-4) : répliquez le pipeline sur l’ensemble des produits concernés. Documentez le processus. Formez les équipes R&D.