La plupart des fabricants découvrent leurs lacunes SBOM lors de leur premier bilan de conformité, et non avant. À ce stade, la date d'application est plus proche et le périmètre de remédiation, plus étendu. L'obligation SBOM de l'Annexe I du CRA est simple à énoncer : format lisible par machine, dépendances de niveau supérieur au moins, conservé dans votre dossier technique Annexe VII. Ce qui piège les fabricants, c'est la formule « au moins ». Cet article couvre six erreurs qui creusent l'écart le plus large entre un SBOM formel et un SBOM capable de résister à un contrôle d'une autorité de surveillance du marché.
Synthèse
- S'arrêter aux dépendances directes laisse les vulnérabilités transitives hors du SBOM
- Un SBOM produit une seule fois devient obsolète en quelques semaines à mesure que de nouveaux CVE sont publiés
- L'absence de valeurs de hachage et d'identifiants PURL fait échouer les contrôles de qualité BSI TR-03183
- La création manuelle de SBOM ne satisfait pas à l'obligation de mise à jour continue du CRA
- Les composants internes et propriétaires doivent figurer aux côtés des bibliothèques open source
- Les SBOM des fournisseurs sont une matière première, pas un artefact de conformité finalisé
Les erreurs en un coup d'œil
| N° | Erreur | Pourquoi elle pose problème | Correctif |
|---|---|---|---|
| 1 | S'arrêter aux dépendances directes | Les CVE transitifs sont invisibles pour les scanners | Fichiers de verrouillage et analyse des artefacts de build |
| 2 | Traiter le SBOM comme un document ponctuel | Obsolète en quelques semaines avec les nouveaux CVE | Génération CI/CD à chaque build |
| 3 | Champs d'identification manquants | Aucun appariement CVE, TR-03183 échoue | Version exacte, SHA-256, PURL, fournisseur |
| 4 | Génération manuelle | Ne peut pas suivre le rythme des versions | Automatisation avec Syft, Trivy ou cdxgen |
| 5 | Omission des composants internes ou propriétaires | L'Annexe I ne fait aucune distinction | Identifiants internes, organisation en tant que fournisseur, SHA-256 |
| 6 | Considérer les SBOM fournisseurs comme définitifs | Le fabricant est seul titulaire de l'obligation Annexe I | Consolidation en un SBOM produit unique |
Erreur 1 : s'arrêter aux dépendances directes
L'Annexe I, Partie II, point (1) fixe le plancher légal aux dépendances de niveau supérieur. Beaucoup de fabricants s'arrêtent exactement là. Le problème ne réside pas dans le fait de respecter le minimum légal. Il réside dans le risque que ce minimum laisse hors de votre visibilité. Une dépendance transitive (une bibliothèque dont dépend votre dépendance directe) est tout aussi exploitable qu'une dépendance directe. Quand un CVE est publié contre un paquet transitif absent de votre SBOM, vous ne pouvez pas l'identifier, ni le signaler, et vous êtes exposé sans le savoir.
Votre produit
+-- Bibliothèque A (directe) ← plancher légal, minimum Annexe I
| +-- Bibliothèque B (transitive) ← hors SBOM, invisible pour les scanners de vulnérabilités
| \-- Bibliothèque C (transitive) ← hors SBOM, invisible pour les scanners de vulnérabilités
\-- Bibliothèque D (directe) ← plancher légal, minimum Annexe I
Le correctif passe par l'outillage et la configuration. Utilisez des fichiers de verrouillage et analysez les artefacts de build plutôt que le seul code source. Trivy, Syft et cdxgen prennent tous en charge la capture des dépendances transitives lorsqu'ils sont correctement configurés. La BSI TR-03183 considère la couverture transitive complète comme l'indicateur de qualité qui distingue un SBOM minimalement conforme d'un SBOM réellement utile. Consultez les niveaux de qualité BSI TR-03183 pour connaître les exigences de champs à chaque niveau.
Erreur 2 : traiter le SBOM comme un document ponctuel
Un SBOM généré une seule fois et jamais mis à jour crée un faux sentiment de sécurité. De nouveaux CVE sont publiés chaque jour contre des composants déjà présents dans votre produit. Un SBOM exact au moment du build devient obsolète en quelques semaines. L'obligation Annexe I du CRA est continue : le SBOM doit refléter l'état actuel du produit tout au long de la période d'assistance.
Déclencheurs de mise à jour obligatoires au titre du CRA :
| Déclencheur | Ce qui change | Mise à jour du SBOM requise ? |
|---|---|---|
| Nouvelle version du firmware ou du logiciel | Nouvel artefact de build | Oui, régénération complète |
| Correctif de sécurité appliqué | Version du composant mise à jour | Oui, composants concernés |
| Vulnérabilité découverte et traitée | Statut VEX ou d'exploitabilité | Oui, champs VEX |
| Composant ajouté, supprimé ou remplacé | Graphe de dépendances | Oui, régénération complète |
| Modification de conception affectant la sécurité | Composants et architecture | Oui, régénération complète |
Le correctif est l'intégration CI/CD. Chaque build doit produire un artefact SBOM à jour conservé aux côtés de la version. Un export manuel ne peut pas suivre la fréquence de mise à jour exigée par le CRA. Consultez les exigences SBOM du CRA pour la liste complète des déclencheurs et l'horloge de conservation sur dix ans.
À compter du 11 septembre 2026, vous devez signaler à l'ENISA les vulnérabilités activement exploitées dans un délai de 24 heures. Un SBOM obsolète vous empêche de déterminer si votre produit est concerné avant que l'horloge commence à tourner. Vous avez besoin de données à jour sur les composants avant l'incident, pas après.
Erreur 3 : champs d'identification manquants
Un SBOM sans version précise, sans valeur de hachage ni identifiants est quasiment inutile pour l'appariement des vulnérabilités. Ces champs relient une entrée de composant à un enregistrement CVE dans la National Vulnerability Database (NVD), OSV ou CISA KEV. Sans eux, les scanners de vulnérabilités ne peuvent pas faire la correspondance avec vos composants, et les contrôles de qualité BSI TR-03183 échouent.
Chaque composant doit inclure :
| Champ | Pourquoi il est important | Source |
|---|---|---|
| Numéro de version exact | Requis pour l'appariement CVE/NVD/OSV (pas « latest » ni des plages) | Annexe I ; TR-03183 obligatoire |
| Hachage SHA-256 | Vérification de l'intégrité des composants binaires | TR-03183 obligatoire |
| Identifiant PURL | Relie le composant à son entrée dans le registre | TR-03183 obligatoire |
| Nom du fournisseur | Requis à tous les niveaux de qualité | Annexe I ; TR-03183 |
Une erreur de version fréquente consiste à utiliser CycloneDX 1.3 ou antérieur. La prise en charge de VEX a été ajoutée dans CycloneDX 1.4 (janvier 2022), et la structure evidence enrichie (identity, occurrences) utilisée pour démontrer la traçabilité CRA est arrivée dans la version 1.5 (juin 2023). Ciblez CycloneDX 1.6 ou supérieur pour la conformité CRA. Vérifiez la version de sortie de votre outil avant de supposer la conformité.
Erreur 4 : générer les SBOM manuellement
La création manuelle de SBOM est source d'erreurs et ne passe pas à l'échelle sur plusieurs versions de produits. Un SBOM rédigé à la main omet des composants que des outils automatisés auraient détectés, contient des fautes de frappe dans les chaînes de version et ne peut pas être régénéré de manière fiable lorsqu'un composant change. Plus important encore, un processus manuel ne peut pas satisfaire à l'obligation de mise à jour continue du CRA : chaque version, chaque correctif et chaque modification de composant nécessite un SBOM mis à jour.
Automatisez la génération avec Syft, Trivy ou cdxgen. Les entrées manuelles doivent être réservées aux composants que les outils automatisés ne peuvent pas détecter, comme les bibliothèques commerciales sans entrée dans les bases de paquets ou les blobs de firmware propriétaires. Tout le reste doit provenir du build. Les autorités de surveillance du marché peuvent demander le SBOM à tout moment ; il doit refléter l'état actuel du produit.
Erreur 5 : ignorer les composants internes et propriétaires
Un raccourci courant consiste à ne documenter que les dépendances open source et à omettre les bibliothèques internes, les modules propriétaires ou les blobs de firmware. L'Annexe I ne fait aucune distinction de ce type. Si un composant est dans le produit, il appartient au SBOM.
Les composants internes n'ont souvent pas de PURL ni d'entrée dans un registre. La bonne approche est d'attribuer un identifiant interne, de lister votre propre organisation comme fournisseur, et d'inclure le hachage SHA-256 de l'artefact binaire. La BSI TR-03183 couvre explicitement les composants propriétaires à tous les niveaux de qualité.
Pour les produits intégrant du firmware provenant d'un ODM ou d'un fournisseur de puces, vous ne pouvez pas auditer ce que vous n'avez pas construit. Le correctif est contractuel : exigez la livraison d'un SBOM de vos fournisseurs de firmware. Au titre du CRA, vous êtes responsable du produit dans son intégralité, indépendamment de l'auteur du code. Pour les produits matériel-logiciel, consultez le HBOM au titre du CRA pour savoir quand une liste de nomenclature matérielle est nécessaire en complément du SBOM.
Erreur 6 : considérer les SBOM fournisseurs comme l'artefact finalisé
Les SBOM des fournisseurs constituent une source d'entrée valide, et le CRA attend des fabricants qu'ils s'appuient sur la documentation amont. Ils ne se substituent pas à un SBOM produit intégré. L'obligation Annexe I incombe au fabricant du produit mis sur le marché de l'UE : vous devez consolider les SBOM des fournisseurs avec vos propres composants, les dépendances de build et le code de liaison en un SBOM unique pour le produit intégré.
Si un SBOM fournisseur est dépourvu des champs requis par la BSI TR-03183 (PURL, hachage, licence), vous êtes responsable de combler ces lacunes avant l'expédition de votre produit. Traitez les SBOM des fournisseurs comme une matière première. Votre SBOM produit est l'artefact de conformité finalisé.
Questions fréquentes
Puis-je réutiliser les SBOM de mes fournisseurs pour satisfaire au CRA ?
Partiellement. Les SBOM des fournisseurs constituent une source valide pour les composants qu'ils livrent, et le CRA attend des fabricants qu'ils s'appuient sur la documentation amont. Cependant, l'obligation prévue par l'Annexe I incombe au fabricant du produit mis sur le marché de l'UE : vous devez produire et maintenir un SBOM pour le produit intégré, ce qui implique de consolider les SBOM des fournisseurs avec vos propres composants, les dépendances de build et tout code de liaison. Si un SBOM fournisseur est dépourvu des champs requis par la BSI TR-03183 (PURL, hachage, licence), vous êtes responsable de combler ces lacunes avant l'expédition de votre produit. Traitez les SBOM des fournisseurs comme une matière première, et non comme un artefact de conformité finalisé.
Quel est le minimum légal de couverture des dépendances SBOM au titre du CRA ?
L'Annexe I, Partie II, point (1) fixe le plancher aux dépendances de niveau supérieur. Le texte officiel dispose que les fabricants « recensent et documentent les vulnérabilités et les composants des produits, notamment par l'établissement d'une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur des produits ». Cela signifie que les dépendances directes sont le minimum légal. Les dépendances transitives ne sont pas légalement requises mais sont fortement recommandées en tant que bonne pratique : ce sont elles dont les scanners de vulnérabilités ont réellement besoin pour apparier les CVE avec précision, et la BSI TR-03183 considère leur couverture comme un indicateur de qualité.
Le SBOM doit-il être mis à jour à chaque version de correctif ?
Oui. Chaque version de correctif de sécurité constitue un déclencheur obligatoire de mise à jour du SBOM au titre du CRA. Le dossier technique, qui inclut le SBOM, doit rester à jour tout au long du cycle de vie du produit. Si vous corrigez un composant vulnérable, votre SBOM doit refléter la nouvelle version. Automatisez la génération du SBOM dans votre CI/CD afin que les versions de correctifs produisent automatiquement un artefact SBOM mis à jour, sans étape manuelle susceptible d'être oubliée sous la pression des délais.