SBOM et dossiers des composants au titre du CRA

Exigence de l’annexe I

identifier et documenter les vulnérabilités et les composants contenus dans les produits comportant des éléments numériques, notamment en établissant une nomenclature logicielle dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau des produits ;

Règlement (UE) 2024/2847, annexe I, partie II, point 1

La SBOM fait partie d’un dossier de composants plus large. Elle aide le fabricant à comprendre quels composants sont inclus dans le produit et quelles vulnérabilités peuvent les affecter.

Éléments à distinguer

Exemple : un dossier de composant traçable

L’exemple fictif suivant décrit une dépendance logicielle directe dans une version du micrologiciel d’un contrôleur. Il illustre les informations techniques utiles ; les champs ne constituent pas un schéma supplémentaire imposé par le CRA.

• Produit : micrologiciel du contrôleur 1.2.0, build de publication 120 ; l’inventaire a été créé à partir du build publié et des données sur ses dépendances.
• Composant : example-parser 2.4.0, fourni par le projet fictif Example Components ; dépendance directe du micrologiciel.
• Identité et origine : identifiant du paquet, révision exacte de la source ou référence du fournisseur, ainsi qu’un condensat réel de l’artefact fourni.
• Utilisation : le composant analyse un fichier de configuration téléversé via une interface de maintenance authentifiée. Consigner les options de build pertinentes et le composant appelant.
• Preuves : créer un lien vers la SBOM lisible par machine et les registres de build ou du fournisseur utilisés pour vérifier cette entrée. Conserver l’inventaire de la version précédente lorsque le composant change.

Le nom et la version d’un composant peuvent aider à trouver des vulnérabilités potentielles. Déterminer si le produit est concerné nécessite une analyse plus poussée : savoir si le code vulnérable est inclus, si la fonction concernée est exécutée, quelle entrée est accessible à un attaquant et quels contrôles sont pertinents. Une correspondance non résolue reste à l’étude ; elle ne prouve pas que le produit n’est pas concerné.

Une déclaration telle que « non concerné » doit préciser la version du produit, la vulnérabilité, la raison technique et les preuves à l’appui. Il faut la réexaminer si une option de build, une version du composant, une interface ou une hypothèse de déploiement change.

Lien avec la documentation technique

L’annexe VII inclut les informations sur les composants et la SBOM dans la documentation technique. Elle demande également des informations sur le processus de traitement des vulnérabilités, la politique de divulgation coordonnée des vulnérabilités, le contact pour les signalements et la distribution sécurisée des mises à jour.

La partie relative au processus est expliquée dans Registres de traitement des vulnérabilités et prEN 40000-1-3 Traitement des vulnérabilités.

Statut du format

L’annexe I exige une SBOM dans un format couramment utilisé et lisible par machine couvrant au minimum les dépendances de premier niveau. L’article 13, paragraphe 24, permet également à la Commission d’en préciser le format et les éléments par acte d’exécution, en tenant compte des normes européennes ou internationales et des bonnes pratiques. Les choix de format doivent donc distinguer le socle fixé par le règlement des exigences d’exécution applicables.

• Une liste de composants au format PDF ne satisfait pas à l’exigence d’un format de SBOM lisible par machine.
• La SBOM identifie les composants ; le traitement des vulnérabilités nécessite également une analyse d’impact, des mesures correctives et une communication.
• L’annexe VII prévoit l’accès à la SBOM sur demande d’une autorité ; elle ne crée pas d’obligation générale de publier la SBOM.