Cyber Resilience Act : SBOM obligatoire et signalement des vulnérabilités

Le Cyber Resilience Act (règlement (UE) 2024/2847, souvent abrégé CRA) est le premier texte européen qui impose des exigences de cybersécurité à tous les produits comportant des éléments numériques vendus dans l'Union : logiciels, objets connectés, équipements. C'est aussi le premier à exiger explicitement un SBOM. Contrairement à NIS2, qui vise des organisations, le CRA vise des produits, et donc leurs fabricants et éditeurs.

NIS2 contrôle la façon dont vous tenez votre maison. Le CRA contrôle ce que vous vendez, comme le marquage CE contrôle la sécurité d'un jouet ou d'un appareil électrique. D'ailleurs, les produits conformes au CRA porteront le marquage CE.

Le calendrier

Nous sommes donc dans la première phase : depuis le 11 septembre 2026, les fabricants doivent déjà signaler les vulnérabilités activement exploitées de leurs produits.

Qui est concerné

Le fabricant d'un produit comportant des éléments numériques mis sur le marché de l'Union européenne, qu'il soit européen ou non. Sont aussi visés, avec des obligations plus légères, les importateurs et distributeurs.

Quelques exclusions importantes :

• les produits déjà couverts par des règles sectorielles spécifiques (dispositifs médicaux, automobile, aviation, par exemple) ;
• le logiciel open source développé ou fourni en dehors d'une activité commerciale ;
• le logiciel fourni comme service en ligne (SaaS) relève en principe de NIS2 plutôt que du CRA, sauf lorsqu'il constitue le traitement de données à distance d'un produit (l'application cloud d'un objet connecté, par exemple).

Si vous éditez un logiciel installé chez vos clients, une application mobile, un firmware ou un objet connecté, vous êtes très probablement concerné.

Obligation 1 : signaler (depuis le 11 septembre 2026)

Quand un fabricant a connaissance d'une vulnérabilité activement exploitée dans son produit, ou d'un incident grave ayant un impact sur sa sécurité, il doit le notifier via la plateforme unique de signalement gérée par l'ENISA, qui transmet au CSIRT national compétent (en France, le CERT-FR de l'ANSSI) :

1. alerte précoce sous 24 heures ;
2. notification sous 72 heures, avec les mesures correctives ou d'atténuation ;
3. rapport final sous 14 jours après la disponibilité d'un correctif (un mois pour un incident grave).

Conséquence pratique : pour signaler en 24 heures qu'une vulnérabilité exploitée touche votre produit, il faut savoir en quelques minutes si le composant concerné est présent, et dans quelles versions. Sans inventaire à jour, c'est impossible. Le SBOM n'est formellement obligatoire qu'en 2027, mais il est indispensable dès maintenant.

Obligation 2 : le SBOM (à partir du 11 décembre 2027)

L'annexe I du règlement impose aux fabricants d'identifier et de documenter les composants et les vulnérabilités de leurs produits, notamment en établissant une nomenclature des logiciels dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau.

Points à retenir :

• le format n'est pas imposé : CycloneDX ou SPDX conviennent tous deux ;
• le SBOM fait partie de la documentation technique remise aux autorités de surveillance du marché sur demande ; il n'est pas obligatoire de le publier ;
• les dépendances de premier niveau sont un minimum : en pratique, un SBOM complet incluant les dépendances transitives est bien plus utile, puisque c'est là que se cachent la plupart des vulnérabilités.

Obligation 3 : gérer les vulnérabilités pendant toute la durée de support

Le CRA impose aussi, entre autres :

• de livrer des produits sans vulnérabilité exploitable connue au moment de la mise sur le marché ;
• de corriger les vulnérabilités sans délai, par des mises à jour de sécurité gratuites, pendant une période de support d'au moins cinq ans en règle générale (ou la durée d'utilisation prévue si elle est plus courte) ;
• de tester et d'examiner régulièrement la sécurité du produit ;
• de publier une politique de divulgation coordonnée des vulnérabilités et un point de contact pour les signalements.

Plan d'action pour un éditeur de logiciel

1. Maintenant : générer un SBOM à chaque build de chaque produit livré, et le conserver pour chaque version publiée.
2. Maintenant : confronter chaque nuit ces SBOM à une base de vulnérabilités à jour, avec un signal spécifique pour les vulnérabilités activement exploitées (catalogue KEV), afin de tenir le délai de 24 heures.
3. Maintenant : écrire la procédure de signalement (qui décide, qui notifie, avec quel modèle) et publier un contact de sécurité (fichier security.txt).
4. D'ici fin 2027 : documenter les décisions sur chaque vulnérabilité (corrigée, non affectée et pourquoi) sous forme de VEX, et intégrer le SBOM à la documentation technique.

Lysbor couvre les points 1, 2 et 4 : inventaire par projet et par version, surveillance quotidienne avec priorisation KEV et EPSS, alerte sur le nouveau, décisions tracées et export CycloneDX et VEX.

Questions fréquentes

Le Cyber Resilience Act s'applique-t-il à un logiciel SaaS ?

En principe non : un service en ligne relève plutôt de NIS2. Il s'applique en revanche au logiciel de traitement de données à distance lorsqu'il est nécessaire au fonctionnement d'un produit (par exemple l'application cloud qui pilote un objet connecté).

Faut-il publier son SBOM ?

Non. Le SBOM fait partie de la documentation technique, à fournir aux autorités de surveillance du marché si elles le demandent. Vous pouvez choisir de le partager avec vos clients, mais ce n'est pas une obligation du CRA.

Quelles vulnérabilités faut-il signaler dès septembre 2026 ?

Les vulnérabilités activement exploitées dans vos produits, et les incidents graves affectant leur sécurité. Il ne s'agit pas de toutes les CVE de vos dépendances, mais de celles dont l'exploitation réelle est avérée.

Le logiciel open source est-il concerné ?

Le logiciel open source développé ou fourni hors activité commerciale est exclu. Les fondations qui soutiennent durablement des projets open source destinés à un usage commercial ont un statut spécifique de « gestionnaire de logiciels open source » avec des obligations allégées. Un éditeur qui intègre de l'open source dans un produit commercial reste, lui, pleinement responsable de ces composants.