SBOM et CRA : ce que le règlement exige vraiment
La nomenclature logicielle est l'une des rares exigences du CRA qui se traduit par un livrable précis. C'est aussi celle sur laquelle circulent le plus d'idées fausses — à commencer par son périmètre.
Ce que dit le règlement
L'exigence figure à l'annexe I, partie II, §1 : le fabricant établit une nomenclature logicielle dans un format lisible par machine, couvrant au minimum les dépendances de premier niveau du produit.
Deux expressions comptent. « Au minimum » : le plancher est fixé, pas le plafond. « Dépendances de premier niveau » : le texte ne demande pas de descendre récursivement dans tout l'arbre des dépendances transitives. Beaucoup d'équipes se bloquent sur un objectif d'exhaustivité que le règlement ne pose pas.
À quoi elle sert concrètement
- Savoir en quelques minutes si une vulnérabilité publiée vous concerne. Sans inventaire, la réponse demande des jours.
- Alimenter la documentation technique (annexe VII), qui doit décrire les composants du produit.
- Soutenir le processus de traitement des vulnérabilités de l'annexe I, partie II — identification, correction, divulgation coordonnée.
- Répondre aux donneurs d'ordre, qui la demandent de plus en plus tôt dans les appels d'offres.
Quel format ?
Le règlement fixe le contenu minimal et exige un format lisible par machine. Deux standards outillés dominent aujourd'hui : CycloneDX (OWASP) et SPDX (Linux Foundation). Les deux sont générables automatiquement par les chaînes de construction courantes.
Le choix du format est une décision d'outillage, pas de conformité. Ce qui compte est que la nomenclature soit exacte, à jour et exploitable.
Trois erreurs fréquentes
Confondre nomenclature et conformité
Une SBOM parfaite ne démontre rien à elle seule. C'est un élément de la documentation technique, pas un certificat.
La générer une seule fois
Une nomenclature figée devient fausse à la première mise à jour. Elle doit être produite par la chaîne de construction, pas maintenue à la main.
Oublier le firmware
Sur un produit industriel, l'essentiel du risque est dans les composants embarqués et les bibliothèques tierces du firmware, pas dans l'application de supervision.
Par où commencer
- Générer une première nomenclature automatiquement depuis la chaîne de construction, même incomplète.
- Vérifier qu'elle couvre les dépendances de premier niveau du produit tel qu'il est livré, firmware compris.
- Brancher une veille de vulnérabilités sur cette liste.
- Rattacher la nomenclature à la documentation technique, et la régénérer à chaque version.
Questions fréquentes
La SBOM doit-elle être publique ?
Le règlement impose de l'établir, de la tenir à jour et de la mettre à disposition des autorités de surveillance du marché sur demande. Il ne fait pas de sa publication une condition de conformité.
Faut-il inclure les dépendances transitives ?
L'exigence porte au minimum sur les dépendances de premier niveau. Aller plus loin est utile pour votre propre veille, mais ce n'est pas le seuil fixé par l'annexe I.
Une SBOM suffit-elle pour être conforme au CRA ?
Non. C'est un des éléments attendus, aux côtés de l'évaluation des risques, des exigences essentielles de conception, du processus de traitement des vulnérabilités, de la documentation technique et de l'évaluation de la conformité.
À quelle fréquence la mettre à jour ?
À chaque version du produit dont le contenu logiciel change. En pratique, cela suppose de la générer automatiquement à la construction plutôt que de la maintenir manuellement.
Source : règlement (UE) 2024/2847, annexe I, partie II.