SBOM et CRA : contenu, outils et obligations

Une alerte touche une bibliothèque : quels produits et quelles versions l’embarquent réellement ? Un SBOM, ou nomenclature logicielle, sert à répondre à cette question. Pour le CRA, produire le fichier ne suffit pas : il faut pouvoir le rattacher à la version distribuée, expliquer ses limites et exploiter les informations pour traiter les vulnérabilités.

Ce que le CRA impose exactement

L’annexe I, partie II, point 1 du règlement (UE) 2024/2847 demande aux fabricants de recenser et documenter les vulnérabilités et les composants, notamment avec une nomenclature dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur.

Le texte ne transforme pas une liste de champs de bonne pratique en obligations littérales : licence, empreinte, identifiant de paquet et arborescence détaillée sont utiles, mais ne sont pas tous énumérés dans cette disposition. L’Art. 13(24) permet à la Commission de préciser le format et les éléments par acte d’exécution. Vérifiez les textes applicables au moment de votre évaluation, sans considérer un export portant le nom d’un standard comme une certification CRA.

Cette exigence relève de l’application générale du 11 décembre 2027. Les signalements CRA sont déjà applicables depuis le 11 septembre 2026. Le rôle de fabricant doit être distingué de celui du simple revendeur dans l’analyse du champ du CRA.

Construire un inventaire utilisable

Voici une grille de travail, et non une reproduction de champs obligatoires fixés par le règlement :

Le minimum légal de niveau supérieur ne dispense pas d’analyser le risque des composants indirects. À l’inverse, annoncer un inventaire exhaustif sans vérifier les binaires, modules chargés à l’exécution ou services associés crée une assurance trompeuse. Consignez les zones non couvertes et leur traitement.

Relier le fichier à ce qui a été livré

Commencez par définir l’objet analysé : dépôt de code, archive distribuée, image de conteneur ou installation comprenant plusieurs modules. Ces objets peuvent contenir des composants différents. Un outil exécuté sur le dépôt ne démontre pas, à lui seul, la composition de l’image remise au client. Rapprochez les références de livraison et celles de la cible analysée.

Préparez une fiche de réception comportant l’identifiant du produit, sa version, l’artefact examiné, la méthode employée et les limites connues. Distinguez la date de génération du SBOM de celle de la livraison. Une nomenclature créée aujourd’hui peut décrire un produit ancien ; inversement, un fichier récent peut avoir été généré sur une branche différente de celle effectivement distribuée.

La comparaison entre deux versions doit permettre de repérer les composants ajoutés, supprimés ou modifiés. Elle ne doit pas effacer la nomenclature antérieure : un client peut encore utiliser l’ancienne version. Organisez donc la recherche par produit et version, avec les références nécessaires pour retrouver les décisions de traitement correspondantes.

Cette fiche est une ressource de travail proposée. Son intérêt est de rendre une affirmation vérifiable : « voici ce que nous avons analysé et ce qui reste hors de cette analyse ». Elle ne crée pas une liste réglementaire supplémentaire de champs obligatoires.

Examiner les écarts avant de conclure

Un rapprochement de composants appelle plusieurs décisions distinctes :

Une valeur inconnue doit rester visible. Remplacer une version absente par la dernière version publiée pour compléter le tableau fausserait les recherches ultérieures. Affectez à chaque incertitude un responsable et une suite : recherche complémentaire, demande fournisseur ou mesure provisoire proportionnée au risque.

Pour l’alerte de vulnérabilité, séparez ensuite la présence du composant, la correspondance avec les versions concernées et les conditions d’exposition du produit. Documenter qu’un chemin d’exploitation n’est pas accessible dans une configuration donnée ne démontre pas que toutes les configurations sont protégées. Toute conclusion doit indiquer son périmètre et les faits qui permettraient de la réexaminer.

Générer puis surveiller : deux fonctions différentes

La documentation officielle de Syft présente la génération de nomenclatures depuis des images de conteneurs et systèmes de fichiers, avec notamment des sorties CycloneDX et SPDX. Pour une équipe qui utilise ces formats, c’est une piste à évaluer sur ses propres artefacts ; le résultat dépend de la cible et de la capacité de détection.

OWASP Dependency-Track reçoit des SBOM CycloneDX et suit les composants des projets et versions pour les rapprocher de sources de vulnérabilités. Cette fonction de suivi complète la génération ; elle ne prouve pas qu’un composant signalé est exploitable dans votre produit.

Le choix de l’outil doit donc inclure une démonstration sur un produit représentatif : composants attendus retrouvés, dépendances inconnues visibles, rattachement à la livraison, import réussi et traitement d’une alerte. Le processus de gestion des vulnérabilités CRA doit désigner qui prend la décision après l’alerte.

Exemple fictif : réception du produit Aulne

Dans cet exercice documentaire entièrement fictif, une équipe prépare la réception d’Aulne 4.2. Trois pièces sont disponibles : une archive destinée aux clients, un SBOM marqué « 4.2 » et une note fournisseur décrivant une bibliothèque modifiée. Le nom de version concorde, mais le dossier ne permet pas encore de relier le SBOM à l’archive précise. La bibliothèque modifiée apparaît sans indication de sa version d’origine.

La réception comporte donc deux réserves différentes. La première concerne l’identité de l’artefact : demander les éléments permettant de rattacher l’analyse à la livraison. La seconde concerne le composant : obtenir la provenance et les modifications pertinentes pour interpréter les alertes. Recevoir une réponse sur la première réserve ne clôt pas automatiquement la seconde.

Supposons ensuite qu’une alerte vise cette bibliothèque. Le responsable recherche les versions d’Aulne concernées, vérifie la correspondance technique et examine les conséquences. Il transmet les éléments utiles à la personne chargée des décisions de correction et de signalement. L’exercice ne permet pas de conclure qu’une exploitation a eu lieu ni qu’une notification est obligatoire : ces qualifications nécessitent leurs propres faits.

Le compte rendu proposé peut tenir en quatre rubriques : pièce examinée, conclusion limitée, réserve restante et action attribuée. La formule « SBOM reçu » est remplacée par une décision explicite sur ce qui est utilisable. Aucun contrôle réel d’Aulne ni essai des logiciels cités dans cet article n’est présenté ici.

Le SBOM doit-il être public ?

Le CRA ne pose pas une obligation générale de publication du SBOM. Le considérant 77 le précise et l’annexe II, point 9 envisage le cas où le fabricant décide de le fournir à l’utilisateur. L’Art. 13(25) prévoit notamment des demandes d’autorités pour certaines évaluations de dépendance ; l’Art. 53 encadre l’accès motivé aux données nécessaires au contrôle.

Préparez une politique de communication : fichier transmis, version, destinataire, informations sensibles et canal. Une demande contractuelle d’un client est à examiner séparément de l’obligation légale. Le dossier de documentation technique CRA doit permettre de retrouver les pièces sans improvisation.

Organiser la transmission et la fin de suivi

Lorsqu’un client demande le fichier, identifiez son besoin : analyser une dépendance, préparer un achat ou suivre une vulnérabilité. Définissez la version transmise et la manière d’annoncer ses limites. Une transmission ponctuelle ne doit pas être décrite comme un engagement de mise à jour continue si le contrat ne le prévoit pas.

Une demande d’autorité appelle une analyse de son fondement et de son périmètre. La confidentialité interne ne suffit pas à écarter une demande relevant du règlement ; elle conduit à organiser la communication et la protection des informations. Conservez la référence de la demande, la réponse et les pièces effectivement communiquées.

Enfin, prévoyez le relais lorsque le responsable change ou qu’une version cesse d’être proposée à la vente. La fin de commercialisation ne signifie pas nécessairement la fin de l’assistance. Le dossier doit encore permettre de retrouver les versions suivies, leurs composants et les décisions prises à leur sujet.

Checklist de réception d’une nomenclature

• Le produit analysé correspond à la livraison, pas seulement au dépôt de code.
• La version, la date et l’outil de génération sont traçables.
• Les limites de couverture sont explicites.
• Les alertes conduisent à une analyse documentée et à un responsable.
• L’historique reste accessible pour les versions encore suivies.

L’Art. 13(13) impose de conserver la documentation technique et la déclaration UE au moins dix ans après la mise sur le marché, ou pendant la période d’assistance si elle est plus longue. La durée du support CRA constitue une décision distincte à justifier.

Ce qu’il faut retenir

• Le CRA exige un SBOM lisible par machine couvrant au moins les dépendances de niveau supérieur.
• Les champs utiles doivent être distingués des exigences textuelles.
• Un fichier généré ne vaut ni analyse de risque ni preuve d’absence de vulnérabilité.
• La publication intégrale du SBOM n’est pas une obligation générale du CRA.

FAQ

Toutes les dépendances indirectes sont-elles expressément exigées ?

La disposition sur la nomenclature fixe un minimum de dépendances de niveau supérieur. Les obligations de gestion des vulnérabilités et l’analyse des risques peuvent nécessiter une connaissance plus large des composants.

Un revendeur doit-il générer lui-même le SBOM ?

L’exigence de l’annexe I vise le fabricant. Le revendeur doit qualifier son rôle et respecter ses obligations propres ; s’il devient fabricant, l’analyse change.

Un SBOM sans alerte prouve-t-il la sécurité ?

Non. L’inventaire peut être incomplet, une vulnérabilité encore inconnue ou le rapprochement défaillant. Il complète les examens de sécurité et le suivi du produit.

Recevez nos analyses conformité dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la conformité numérique.