Cyber Resilience Act : SBOM, vulnérabilités et signalements de l'article 14
Le règlement (UE) 2024/2847 impose aux fabricants de produits comportant des éléments numériques (logiciel, objet connecté, firmware) de connaître les composants de leurs produits, d'en suivre les vulnérabilités et, depuis le 11 septembre 2026, de signaler celles qui sont activement exploitées. Voici ce que demande le texte et ce que fait Lysbor pour chaque point.
Lysbor vous aide à respecter ces obligations ; il ne certifie pas la conformité de votre produit et ne dépose aucune déclaration à votre place.
Le calendrier
Dates fixées par l'article 71, paragraphe 2, du règlement. Nous sommes dans la première phase : les signalements de l'article 14 s'appliquent déjà, le reste des exigences suit fin 2027.
10 décembre 2024Entrée en vigueur du règlement (UE) 2024/2847.
11 septembre 2026Obligations de signalement de l'article 14 : vulnérabilités activement exploitées et incidents graves.
11 décembre 2027Application de l'ensemble des exigences, dont le SBOM de l'annexe I.
Article 14 : trois échéances pour une vulnérabilité activement exploitée
La notification est adressée simultanément au CSIRT désigné comme coordinateur (en France, le CERT-FR de l'ANSSI) et à l'ENISA, par la plateforme unique de signalement. Une vulnérabilité activement exploitée est, selon l'article 3, point 42, une vulnérabilité pour laquelle il existe des preuves fiables qu'un acteur malveillant l'a exploitée sans l'autorisation du propriétaire du système.
24 h
Alerte précoce
Au plus tard 24 heures après la prise de connaissance, en indiquant le cas échéant les États membres où le produit a été mis à disposition (article 14, paragraphe 2, point a).
72 h
Notification de vulnérabilité
Au plus tard 72 heures après la prise de connaissance : produit, nature de l'exploitation et de la vulnérabilité, mesures prises et mesures possibles pour les utilisateurs (point b).
14 jours
Rapport final
Au plus tard 14 jours après la mise à disposition d'une mesure de correction ou d'atténuation : gravité, répercussions, mise à jour de sécurité (point c).
Dans Lysbor, chaque déclaration affiche ces trois échéances avec un compte à rebours. Les délais sont calculés de façon prudente : 24 et 72 heures de temps écoulé depuis la prise de connaissance, 14 jours calendaires à la même heure de Paris.
Obligation par obligation, ce que fait Lysbor
À gauche, ce que demande le règlement ; à droite, ce que fait Lysbor, et dans quelles offres.
SBOM
Ce que demande le CRA : Annexe I : identifier et documenter les composants du produit, notamment par une nomenclature des logiciels dans un format couramment utilisé et lisible par machine, couvrant au minimum les dépendances de premier niveau.
Import de SBOM CycloneDX et SPDX, par envoi de fichier, par l'API ou par l'agent lysbor-scan à chaque build (GitHub Actions, GitLab CI). Lockfiles et images de conteneurs acceptés aussi. Export CycloneDX enrichi des vulnérabilités, à tout moment.
Toutes les offres
Suivi des vulnérabilités
Ce que demande le CRA : Identifier les vulnérabilités des composants du produit et les traiter sans délai pendant la période de support.
Chaque inventaire confronté à la base OSV chaque nuit, toutes les 6 heures ou toutes les heures selon l'offre. Paquets système Debian, Ubuntu et Alpine comparés par paquet source. Une faille déjà présente qui entre au catalogue CISA KEV est signalée dans l'heure. Plan de correction ordonné.
Toutes les offres, priorisation KEV et EPSS affichée à partir de Team
Firmware et composants C/C++
Ce que demande le CRA : Le SBOM et le suivi valent aussi pour un firmware ou un objet connecté, dont les composants n'ont souvent pas de gestionnaire de paquets.
Les composants sans écosystème OSV (Yocto, Buildroot, C/C++ embarqué) sont comparés à la NVD par leur CPE. Une version illisible est listée à vérifier, jamais alertée. Les CVE du noyau Linux sont regroupées dans un bloc à part, hors des compteurs, sauf celles inscrites au catalogue KEV ou dont l'EPSS atteint 10 %.
Toutes les offres
Décisions et VEX
Ce que demande le CRA : Annexe I : documenter les vulnérabilités des composants. Le format VEX est une façon courante de dire ce qui en est fait : corrigée, non concernée et pourquoi, risque accepté.
Chaque décision porte une qualification VEX (risque accepté, faux positif, non concerné avec sa justification) et reste d'un envoi à l'autre. Export VEX CycloneDX. Un risque accepté n'est jamais exporté comme « non affecté ».
Décisions dans toutes les offres, export VEX à partir de Team
Signalement de l'article 14
Ce que demande le CRA : Vulnérabilité activement exploitée : alerte précoce sous 24 heures, notification sous 72 heures, rapport final au plus tard 14 jours après la mise à disposition d'une mesure corrective, au CSIRT coordinateur (en France, le CERT-FR) et à l'ENISA, via la plateforme unique de signalement.
Quand une vulnérabilité ouverte d'un projet est inscrite au catalogue CISA KEV, Lysbor ouvre une déclaration et calcule les trois échéances ; vous pouvez aussi en ouvrir une vous-même. Rappels aux propriétaires et administrateurs à l'ouverture, 6 heures avant chaque échéance et à son dépassement. Un brouillon par étape, structuré selon l'article 14, à copier ou exporter en texte ou en JSON.
Team, Business et l'essai de 14 jours
Preuve
Ce que demande le CRA : Pouvoir montrer, à une autorité de surveillance du marché ou à un client, l'état des composants et des décisions.
Rapport PDF de posture (tendance, décisions et justifications), journal d'activité chaîné par hash où sont tracées les décisions « non applicable » et chaque étape déclarée envoyée.
Rapport PDF dans toutes les offres, export CSV du journal à partir de Team
Ce que Lysbor ne fait pas
Lysbor ne transmet aucune déclaration : vous la relisez, la complétez et la déposez vous-même sur la plateforme unique de signalement.
Lysbor ne certifie pas la conformité de votre produit et ne remplace ni l'analyse de risque, ni la documentation technique, ni l'évaluation de la conformité.
L'inscription au catalogue CISA KEV est un indice fort d'exploitation active, à confirmer pour votre produit : un composant présent mais jamais chargé, par exemple, se discute. Lysbor vous laisse marquer la déclaration « non applicable », avec une justification tracée.
Le régime des incidents graves (article 14, paragraphes 3 à 5) est expliqué dans nos guides, pas suivi dans l'application.
À voir dans la démonstration
Une déclaration en cours
CVE-2025-24813 (Apache Tomcat), inscrite au catalogue CISA KEV, dans le service de paiement Java : alerte précoce envoyée avec sa référence, notification à faire avant l'échéance, rapport final en attente du correctif. Le brouillon de chaque étape se lit, se copie et s'exporte.
Le firmware d'une passerelle IoT
Le projet passerelle-iot-firmware : un SBOM SPDX produit par Yocto, des composants C/C++ comparés à la NVD par leur CPE, et les CVE du noyau Linux regroupées dans leur bloc.
Lysbor rend-il mon produit conforme au Cyber Resilience Act ?
Non, aucun outil ne le fait seul. Lysbor vous aide à respecter plusieurs obligations du règlement : tenir le SBOM de chaque produit à jour, suivre ses vulnérabilités, documenter vos décisions et tenir les délais de signalement de l'article 14. La conformité reste celle du fabricant.
Quelles vulnérabilités ouvrent une déclaration dans Lysbor ?
Celles d'un de vos projets qui sont inscrites au catalogue CISA KEV des vulnérabilités exploitées. Vous pouvez aussi ouvrir une déclaration vous-même si vous apprenez une exploitation par une autre source, ou la marquer « non applicable » avec une justification.
Lysbor envoie-t-il la déclaration au CERT-FR ?
Non. Lysbor calcule les échéances, vous les rappelle et prépare un brouillon par étape avec ce qu'il sait (composant, version, CVE, sévérité, exploitation, versions corrigées). Ce qu'il ne peut pas savoir est signalé à compléter. Le dépôt sur la plateforme unique de signalement reste le vôtre.
Mon produit est un firmware en C, sans gestionnaire de paquets. Lysbor le suit-il ?
Oui, à partir d'un SBOM CycloneDX ou SPDX (celui de Yocto, par exemple). Les composants sans écosystème OSV sont comparés à la NVD par leur CPE. La démonstration contient le firmware d'une passerelle IoT suivi de cette façon.
Quelle offre choisir pour le CRA ?
Le suivi des signalements de l'article 14 et l'export VEX sont inclus à partir de Team. Starter couvre le SBOM, la surveillance des vulnérabilités, le rapport PDF et l'export CycloneDX. L'essai de 14 jours donne accès à tout ce que propose Team.