Ce que le CRA demande à votre SBOM
L'annexe I demande au moins les dépendances de premier niveau, à partir du 11 décembre 2027. Ce que ça change pour un petit éditeur.
La SBOM revient dans toutes les pages qui parlent du Cyber Resilience Act. Un développeur qui vend un produit se pose alors une question courte. Faut-il en produire une cette semaine, et à quoi doit-elle ressembler ?
La date
L’obligation de SBOM fait partie du traitement des vulnérabilités. Elle s’applique le 11 décembre 2027, avec le reste du règlement prévu par l’article 71.
Au même moment arrivent la documentation technique (annexe VII), l'évaluation de la conformité, le marquage CE et la déclaration UE. Les amendes s’appliquent aussi à partir de décembre 2027 (article 64).
Rien de tout ça n’est dû aujourd’hui. Ce qui s’applique depuis le 11 septembre 2026, c’est l’article 14.
Ce que dit l’annexe I
Annexe I, partie II, point 1 : une SBOM couvrant au moins les dépendances de premier niveau du produit.
« Au moins » est le mot qui compte. C’est un plancher. Vos dépendances directes, celles que vous avez écrites vous-même dans votre fichier de dépendances.
Pour un projet Node, ce sont les entrées de votre package.json, pas les 400 paquets que npm install finit par installer. Pour un projet Python, les lignes de votre requirements.txt ou de votre pyproject.toml.
Le plancher est bas. Il est atteignable en une commande, dès aujourd’hui, sans acheter d’outil.
Pourquoi le faire avant 2027
L’article 14 s’applique maintenant. Si vous apprenez qu’une vulnérabilité de votre produit est activement exploitée, vous avez 24 heures pour l’alerte précoce et 72 heures pour la notification complète. Destinataires : le CSIRT coordinateur de votre État membre et l’ENISA.
Le compte à rebours démarre quand vous en avez connaissance, pas quand une autorité vous écrit.
« Activement exploitée » a une définition précise : des éléments fiables indiquant qu’un acteur malveillant a exploité la vulnérabilité dans un système sans l’autorisation du propriétaire (article 3, point 42).
Le jour où un bulletin passe sur une bibliothèque que vous embarquez, la première question est : est-ce que je l’embarque ? Sans liste à jour, la réponse prend une demi-journée. Avec une liste, elle prend trente secondes.
La SBOM de 2027 vous sert donc déjà en 2026, pour une raison qui n’a rien à voir avec l’annexe I.
Un exemple
Prenons un cas de figure. Un développeur vend un client de bureau construit avec Electron. Licence unique, quelques milliers d’installations. Imaginons son package-lock.json à 380 paquets, et son package.json à 34 lignes.
Il passe son fichier de verrouillage dans l’analyse gratuite. Disons que le résultat donne sept vulnérabilités connues via OSV.dev, dont une marquée au catalogue CISA KEV, la liste d’environ 1 700 failles dont l’exploitation a été observée.
La faille marquée KEV se trouve dans une dépendance transitive. Elle n’apparaît pas dans ses 34 lignes de premier niveau.
Le plancher de l’annexe I ne l’aurait pas montrée. L’arbre complet l’a montrée. Garder l’arbre entier coûte le même clic quand l’outil le génère.
Ce qu’il fait ensuite tient en trois gestes. Il monte la version. Il regarde si son produit appelle vraiment le code vulnérable. Il garde le fichier SBOM daté, parce que dans quinze mois il devra montrer une pratique, pas une bonne intention.
Une marque KEV n’est pas une notification
Un paquet présent dans le catalogue KEV signale une exploitation observée quelque part. Cela ne dit pas que votre produit est exploité, ni que le chemin vulnérable est atteignable chez vous.
L’article 14 vise la vulnérabilité de votre produit, pas l’actualité d’une bibliothèque. La qualification vous revient, et elle mérite parfois un avis extérieur.
Le catalogue sert à trier. Il place une entrée en haut de la pile de lecture du lundi matin.
Les limites de l’outil
L’analyse gratuite tourne dans le navigateur. Seuls les identifiants de paquets partent vers OSV.dev. Elle lit 20 formats de fichiers de verrouillage et de manifestes, plus les CycloneDX et SPDX existants, et sort une SBOM CycloneDX 1.5.
Gradle n’est pas pris en charge. Pour Maven, les versions gérées ou définies par propriété sont ignorées.
Il n’y a pas de surveillance continue. Vous relancez l’analyse quand vous publiez, ou quand un bulletin vous intrigue.
Avant la SBOM
Une SBOM ne sert à rien si le règlement ne vous vise pas. Le SaaS pur en navigateur reste hors champ (considérant 12), et le logiciel libre fourni hors activité commerciale aussi (considérant 18).
Le test de périmètre prend deux minutes et donne les références d’articles : https://crakit.eu/fr/champ-d-application/
Ce n’est pas un conseil juridique.
Ce n’est pas un conseil juridique.