Erreurs SBOM courantes sous le CRA : comment les éviter
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-512, 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-512 |
| 6 | Considérer les SBOM fournisseurs comme définitifs | Le fabricant reste responsable de la SBOM produit intégrée | Consolider en un SBOM produit unique |
Erreur 1 : s'arrêter aux dépendances directes
Les dépendances directes sont le minimum acceptable, mais elles ne suffisent pas pour une gestion utile des vulnérabilités. Beaucoup de fabricants s'arrêtent là et laissent les dépendances transitives hors de la SBOM. Une dépendance transitive est une bibliothèque dont dépend votre dépendance directe, et elle peut être aussi exploitable qu'une dépendance directe. Lorsqu'un CVE est publié contre un paquet transitif absent de votre SBOM, vous ne pouvez pas l'identifier, ni le signaler, et vous restez 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 catégories de champs BSI TR-03183 pour connaître les exigences de champs Obligatoires, Additionnels et Optionnels.
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 au CSIRT coordinateur et à 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) | TR-03183 obligatoire |
| Hachage SHA-512 | 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 Additionnel (si disponible) |
| Nom du fournisseur | Requis pour chaque composant | 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-512 de l'artefact binaire. La BSI TR-03183 couvre explicitement les composants propriétaires, et ses champs Obligatoires leur sont également applicables.
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. Elles ne remplacent pas une SBOM produit intégrée. Vous devez toujours consolider les SBOM des fournisseurs avec vos propres composants, les dépendances de build et le code de liaison en une seule SBOM pour le produit que vous mettez sur le marché de l'UE.
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 sont une source valide pour les composants qu'ils livrent, et vous devez les utiliser plutôt que recréer la documentation amont à partir de zéro. Elles ne suffisent pas seules : il vous faut une SBOM pour le produit intégré, combinant les SBOM fournisseurs avec vos propres composants, les dépendances de build et le code de liaison. Si une SBOM fournisseur manque de champs BSI TR-03183 comme le PURL, le hachage ou la licence, comblez ces lacunes avant l'expédition. Traitez les SBOM fournisseurs comme une matière première, pas comme l'artefact de conformité finalisé.
Quel est le minimum légal de couverture des dépendances SBOM au titre du CRA ?
Le plancher légal correspond aux dépendances de niveau supérieur, c'est-à-dire aux dépendances directes. Ce n'est que le minimum. Les dépendances transitives sont fortement recommandées, car les scanners de vulnérabilités en ont besoin pour apparier les CVE avec précision, et BSI TR-03183 traite la couverture transitive comme un indicateur de qualité. En pratique, générez votre SBOM à partir des fichiers de verrouillage et des artefacts buildés afin de capturer les dépendances directes et transitives.
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.