Cyber Resilience Act et SBOM : inventorier un binaire livré sans inventaire

Le 11 septembre 2026, l'ENISA a ouvert la plateforme unique de signalement du Cyber Resilience Act. Depuis ce jour, un fabricant de produit comportant des éléments numériques doit y notifier les vulnérabilités activement exploitées et les incidents graves qui touchent ses produits¹. Pour signaler une faille dans un composant, encore faut-il savoir que le composant est là. Quand un fournisseur livre un binaire sans inventaire, l'analyse par agent aide à reconstruire une base de travail.

Le Cyber Resilience Act en bref

Le Cyber Resilience Act est le règlement (UE) 2024/2847. Il impose des exigences de cybersécurité aux produits comportant des éléments numériques, matériels comme logiciels, sur l'ensemble de leur cycle de vie. Il est entré en vigueur le 10 décembre 2024².

Le texte vise le fabricant qui met un produit sur le marché européen. Une DSI qui intègre des composants tiers dans un produit qu'elle commercialise devient fabricant à son tour. Une DSI qui achète un logiciel pour son usage interne n'est pas fabricant, mais elle hérite du problème : pour suivre les vulnérabilités de ce qu'elle exploite, elle a besoin d'information sur les composants, que ses fournisseurs ne sont pas tenus de lui donner sous forme de SBOM.

Le calendrier à retenir

Deux dates comptent. Les obligations de signalement de l'article 14 s'appliquent depuis le 11 septembre 2026. Pour une vulnérabilité activement exploitée, le fabricant envoie une alerte précoce dans les 24 heures après en avoir pris connaissance, une notification plus complète dans les 72 heures, et un rapport final au plus tard 14 jours après la mise à disposition d'une mesure corrective. Pour un incident grave, le rapport final arrive un mois après la notification de 72 heures².

L'application générale du règlement, avec les exigences essentielles de cybersécurité et le marquage CE, interviendra le 11 décembre 2027².

Côté outil, l'ENISA a déployé le 11 septembre 2026 une « initial operating capability » de sa plateforme de signalement, destinée aux fabricants et aux gestionnaires de logiciels libres. À l'ouverture, elle fonctionne par interface web, sans API, en anglais ; le signalement volontaire prévu à l'article 15 viendra dans une phase ultérieure¹.

Le lien avec la nomenclature logicielle

Parmi les exigences de traitement des vulnérabilités, le règlement demande au fabricant d'identifier et de documenter les composants de son produit, notamment au moyen d'une nomenclature logicielle (SBOM, software bill of materials) dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau². Cette exigence figure à l'annexe I parmi les exigences essentielles : elle s'applique au 11 décembre 2027, pas avec le signalement de septembre 2026. Le règlement n'oblige pas le fabricant à transmettre sa SBOM à ses clients ; il peut choisir de la mettre à disposition, et les autorités de surveillance du marché peuvent la demander.

Un composant fournisseur livré en binaire, sans inventaire, crée une zone d'ombre dans cette documentation. Quelles bibliothèques embarque-t-il, dans quelles versions ? Sans réponse, impossible de savoir si une vulnérabilité publiée vous concerne, et donc de tenir des délais comptés en heures.

La méthode

Un agent équipé de REA lit un binaire sans son code source. Sur un exécutable natif, il pilote Ghidra, Hopper ou IDA et rend chaînes, symboles et références. Pour un binaire Rust compilé avec cargo-auditable, il lit les noms, versions et sources des crates embarquées ; pour un binaire Go, la version du compilateur et les modules ; pour une assembly .NET, les métadonnées et les dépendances natives déclarées ; pour une application Electron, les modules JavaScript³.

La démarche tient en quatre temps. Analyser le binaire avec le moteur adapté. Extraire bibliothèques, versions et dépendances. Recouper avec les bases de vulnérabilités (identifiants CVE). Produire un inventaire daté qui garde visibles les inconnues de l'analyse. Lisez ces inconnues comme un trou dans l'inventaire, jamais comme une absence de composant ; notre page sur la lecture d'une sortie REA détaille cette discipline.

L'inventaire ainsi reconstruit n'est pas la SBOM officielle du fournisseur. Il sert de base de travail : il documente votre diligence, nourrit la discussion contractuelle et permet de réagir plus vite le jour où une vulnérabilité sort. Notre page sur l'audit d'un binaire fournisseur décrit les vérifications préalables complètes.

Deux précautions

Un binaire fournisseur inconnu s'ouvre dans un environnement isolé. REA le dit dans sa politique de sécurité : l'outil n'est pas un bac à sable, et ouvrir un binaire non fiable délègue son analyse au moteur local avec les permissions de l'utilisateur⁴. Voir comment confiner l'analyse. Vérifiez aussi la provenance de l'outil lui-même : un faux dépôt REA a distribué un cheval de Troie en octobre 2026 (le récit de l'incident).

Côté droit, analyser un logiciel que vous êtes autorisé à examiner reste le cas sain. Relisez la clause de rétro-ingénierie de votre contrat avec notre page sur les clauses de licence nulles en France, et le hub juridique du dossier.

Questions fréquentes

Quand le CRA s'applique-t-il ?

Les obligations de signalement s'appliquent depuis le 11 septembre 2026 ; l'application générale interviendra le 11 décembre 2027.

Une SBOM reconstruite vaut-elle inventaire officiel ?

Non. Elle complète l'information du fournisseur et documente votre diligence, sans engager le fabricant.

Où signaler une vulnérabilité activement exploitée ?

Sur la plateforme unique de signalement de l'ENISA, ouverte le 11 septembre 2026. Le fabricant choisit un CSIRT coordinateur, qui relaie la notification aux autres États membres concernés.

Une DSI qui achète un logiciel est-elle concernée ?

Pas comme fabricant, sauf si elle intègre le composant dans un produit qu'elle met sur le marché. Le règlement ne l'oblige pas à recevoir de SBOM : à elle de demander l'inventaire par contrat.

L'offre AI Cyber analyse en boîte blanche le code source de vos applications, et sans le code source les composants que vous recevez en binaire, pour savoir ce qu'ils contiennent avant qu'une vulnérabilité ne vous oblige à le découvrir dans l'urgence.

Sources

1. ENISA, The CRA Single Reporting Platform is launched — enisa.europa.eu, 11 septembre 2026.
2. Règlement (UE) 2024/2847 du Parlement européen et du Conseil du 23 octobre 2024 concernant des exigences de cybersécurité horizontales pour les produits comportant des éléments numériques (Cyber Resilience Act), articles 14 et 71, annexe I — eur-lex.europa.eu.
3. morluto/rea, README, tableau « What you can analyze » — github.com/morluto/rea, consulté le 17 octobre 2026.
4. morluto/rea, SECURITY.md — github.com/morluto/rea, consulté le 17 octobre 2026.