Points cl\u00e9s<\/h2>\n\n- Le Cyber Resilience Act est en vigueur depuis le 11 d\u00e9cembre 2024. L’obligation de signalement pour les vuln\u00e9rabilit\u00e9s activement exploit\u00e9es et les incidents graves prend effet le 11 septembre 2026 (EU Digital Strategy, 2026).<\/li>\n
- L’applicabilit\u00e9 int\u00e9grale du CRA, avec l’ensemble des exigences techniques pour les produits comportant des \u00e9l\u00e9ments num\u00e9riques, d\u00e9butera le 11 d\u00e9cembre 2027.<\/li>\n
- La cha\u00eene de signalement comporte trois niveaux : une alerte pr\u00e9coce sous 24 heures, un rapport complet sous 72 heures, et un rapport final sous 14 jours apr\u00e8s la disponibilit\u00e9 de la mesure corrective.<\/li>\n
- Les signalements transitent par la CRA Single Reporting Platform vers le CSIRT comp\u00e9tent du pays o\u00f9 se situe le si\u00e8ge social. L’ENISA re\u00e7oit l’information en parall\u00e8le, sans qu’une d\u00e9claration suppl\u00e9mentaire soit n\u00e9cessaire.<\/li>\n
- Les SBOM (Software Bill of Materials) ne sont plus une simple recommandation, mais une composante obligatoire de la gestion des vuln\u00e9rabilit\u00e9s. Sans transparence des composants, un signalement ne peut \u00eatre justifi\u00e9 de mani\u00e8re satisfaisante.<\/li>\n<\/ul>\n
Ce que l’obligation de signalement du CRA implique concr\u00e8tement \u00e0 compter de septembre 2026<\/h2>\n
Le Cyber Resilience Act (CRA) constitue le premier r\u00e8glement europ\u00e9en relatif \u00e0 la cybers\u00e9curit\u00e9 des produits. Il vise les fabricants, les importateurs et les distributeurs de produits comportant des \u00e9l\u00e9ments num\u00e9riques – c’est-\u00e0-dire pratiquement tout ce qui contient un logiciel ou est connect\u00e9 en r\u00e9seau. Sont concern\u00e9s les \u00e9diteurs de logiciels classiques tout comme les fabricants de mat\u00e9riel disposant de syst\u00e8mes embarqu\u00e9s, les fournisseurs d’appareils m\u00e9nagers connect\u00e9s, de capteurs industriels, de passerelles IoT et de produits b\u00e9n\u00e9ficiant de mises \u00e0 jour de micrologiciel (firmware). L’application compl\u00e8te est pr\u00e9vue pour le 11 d\u00e9cembre 2027, mais un bloc d’obligations essentiel entre en vigueur plus t\u00f4t : \u00e0 partir du 11 septembre 2026, les fabricants devront signaler les vuln\u00e9rabilit\u00e9s activement exploit\u00e9es et les incidents de s\u00e9curit\u00e9 graves.<\/p>\n
Cette obligation de signalement repr\u00e9sente, sur le plan op\u00e9rationnel, la partie la plus critique du CRA. Elle int\u00e8gre directement les \u00e9quipes de s\u00e9curit\u00e9 informatique dans les processus r\u00e9glementaires et cr\u00e9e une interface rigide entre la gestion des vuln\u00e9rabilit\u00e9s et la communication avec les autorit\u00e9s. Les produits mis sur le march\u00e9 apr\u00e8s la date limite rel\u00e8vent int\u00e9gralement de l’obligation de signalement. Des r\u00e8gles transitoires s’appliquent aux produits existants, mais d\u00e8s qu’une mise \u00e0 jour est d\u00e9ploy\u00e9e, le fabricant doit \u00eatre en mesure d’activer la cha\u00eene de signalement du CRA.<\/p>\n
L’Office f\u00e9d\u00e9ral de la s\u00e9curit\u00e9 des technologies de l’information (BSI) a pr\u00e9cis\u00e9, dans le cadre de son initiative de conseil sur le CRA, qu’il s’agit d’obligations de signalement op\u00e9rationnelles et non de simple documentation de conformit\u00e9 formelle. Les d\u00e9lais sont stricts. Les destinataires sont clairement d\u00e9finis. Le contenu des rapports est exigeant, tant techniquement que sur le fond. Un rapport standard pilot\u00e9 par le marketing ne suffit pas – il faut fournir des indications pr\u00e9cises sur les produits concern\u00e9s, les exploits, le statut des mesures d’att\u00e9nuation et la disponibilit\u00e9 des correctifs.<\/p>\n
\nD\u00e9finition<\/p>\n
Une vuln\u00e9rabilit\u00e9 activement exploit\u00e9e<\/strong> au sens du CRA est une faille pour laquelle existent des indices document\u00e9s d’une exploitation r\u00e9elle – que ce soit via le renseignement sur les menaces (Threat Intelligence), un incident au sein de sa propre client\u00e8le ou un signalement externe v\u00e9rifi\u00e9. La simple existence d’une preuve de concept (Proof-of-Concept) ne suffit pas ; ce qui est d\u00e9terminant, c’est la preuve de l’utilisation contre un syst\u00e8me en production.<\/p>\n<\/div>\nL’horloge 24-72-14 : les cha\u00eenes de signalement en d\u00e9tail<\/h2>\n
Les trois d\u00e9lais du CRA (Cyber Resilience Act) pour les vuln\u00e9rabilit\u00e9s activement exploit\u00e9es s’encha\u00eenent et contraignent les \u00e9quipes de s\u00e9curit\u00e9 \u00e0 adopter une routine d’escalade clairement cadenc\u00e9e. Le chronom\u00e8tre commence \u00e0 tourner d\u00e8s que le fabricant a connaissance de l’exploitation active. \u00c0 partir de ce moment, il reste 24 heures pour une Early Warning (alerte pr\u00e9coce), qui contient les informations fondamentales sur la vuln\u00e9rabilit\u00e9, le produit concern\u00e9 et l’\u00e9tat des connaissances. L’Early Warning n’est pas une d\u00e9claration compl\u00e8te, mais un signal d’alerte pr\u00e9coce destin\u00e9 aux autorit\u00e9s.<\/p>\n
Dans les 72 heures suivant cette m\u00eame prise de connaissance, la d\u00e9claration compl\u00e8te doit suivre. Elle contient des informations sur la nature de la vuln\u00e9rabilit\u00e9, les versions de produits concern\u00e9es, les premi\u00e8res recommandations d’att\u00e9nuation et l’\u00e9tat actuel de la gestion de l’incident. Quiconque ne respecte pas ce cr\u00e9neau de 72 heures enfreint l’une des obligations centrales de conformit\u00e9 du CRA. La cons\u00e9quence pratique est que les processus de r\u00e9ponse aux incidents doivent, d\u00e8s le premier jour ouvrable suivant la d\u00e9couverte, non seulement fonctionner techniquement, mais aussi \u00eatre pr\u00eats \u00e0 d\u00e9clarer sur le plan r\u00e9glementaire.<\/p>\n
La troisi\u00e8me \u00e9tape est le rapport final. Pour les vuln\u00e9rabilit\u00e9s activement exploit\u00e9es, un d\u00e9lai de 14 jours s’applique \u00e0 compter de la disponibilit\u00e9 d’une mesure corrective – c’est-\u00e0-dire \u00e0 partir du moment o\u00f9 le correctif peut \u00eatre d\u00e9ploy\u00e9. Pour les incidents de s\u00e9curit\u00e9 graves, cette p\u00e9riode est \u00e9tendue \u00e0 un mois. Le rapport final documente la cause racine, les mesures prises, l’\u00e9tat du d\u00e9ploiement du correctif et les enseignements pour les futures versions du produit. Il constitue la base des audits ult\u00e9rieurs men\u00e9s par l’ENISA et les autorit\u00e9s nationales.<\/p>\n
\n24 \/ 72 \/ 14<\/div>\nHeures Early Warning, Heures D\u00e9claration compl\u00e8te, Jours Rapport final – le rythme de signalement du CRA \u00e0 partir du 11 septembre 2026<\/div>\nSource : EU Digital Strategy, CRA Reporting Obligations 2026<\/div>\n<\/div>\nQui d\u00e9clare au sein de l’entreprise et vers qui ?<\/h2>\n
Les d\u00e9clarations au titre du Cyber Resilience Act (CRA) transitent centralement par la CRA Single Reporting Platform – un syst\u00e8me de d\u00e9claration g\u00e9r\u00e9 par l’ENISA qui pr\u00e9voit une saisie unique. Le fabricant adresse formellement la d\u00e9claration au Computer Security Incident Response Team (CSIRT) de l’\u00c9tat membre de son si\u00e8ge social. En Allemagne, l’autorit\u00e9 comp\u00e9tente est le BSI (Bundesamt f\u00fcr Sicherheit in der Informationstechnik) ou le CERT-Bund. L’information est transmise en parall\u00e8le \u00e0 l’ENISA, sauf dans des cas d’exception clairement d\u00e9finis pr\u00e9sentant des int\u00e9r\u00eats de s\u00e9curit\u00e9 particuliers.<\/p>\n
Pour les entreprises disposant de plusieurs sites de production ou de filiales dans diff\u00e9rents \u00c9tats membres de l’UE, la r\u00e8gle du si\u00e8ge social est d\u00e9terminante. Elle d\u00e9finit quel CSIRT est comp\u00e9tent, quelles directives nationales s’appliquent et qui doit \u00eatre contact\u00e9 en cas de questions. Les conglom\u00e9rats aux structures mixtes doivent documenter proprement cette attribution et clarifier au sein de l’organisation qui d\u00e9clenche la d\u00e9claration en cas d’urgence. Un simple responsable produit sans mandat pour la communication avec les autorit\u00e9s \u00e9chouera face \u00e0 la r\u00e9alit\u00e9 du CRA.<\/p>\n
Au sein de l’entreprise, la d\u00e9claration CRA n\u00e9cessite une responsabilit\u00e9 clairement d\u00e9finie. Elle r\u00e9side typiquement au sein du Product Security Incident Response Team (PSIRT), en lien direct avec le bureau du CISO (Chief Information Security Officer). Ceux qui ne disposent pas encore d’un PSIRT doivent mettre en place cette fonction avant la date limite. L’alternative consiste \u00e0 contraindre les \u00e9quipes de d\u00e9veloppement ad hoc \u00e0 la proc\u00e9dure de d\u00e9claration – ce qui ne s’adapte pas \u00e0 l’\u00e9chelle et \u00e9chouera face aux d\u00e9lais de 24 heures. La question des ressources humaines est au moins aussi importante que la pr\u00e9paration technique.<\/p>\n
Ce qu’un processus de r\u00e9ponse aux incidents pr\u00eat pour le CRA doit accomplir<\/h2>\n
Un processus conforme au Cyber Resilience Act (CRA) repose sur trois piliers : la d\u00e9tection, l’\u00e9valuation et le signalement. La d\u00e9tection signifie que le fabricant identifie pr\u00e9cocement l’exploitation active – gr\u00e2ce \u00e0 la surveillance de ses propres produits, \u00e0 l’analyse de flux de Threat Intelligence, aux canaux de divulgation coordonn\u00e9e des vuln\u00e9rabilit\u00e9s (CVD) et \u00e0 l’int\u00e9gration aux structures des ISAC (Information Sharing and Analysis Centers). Un fabricant qui r\u00e9agit uniquement aux plaintes de clients se trouve en position d\u00e9savantageuse, car il atteint tardivement le seuil de connaissance et que l’horloge des 24 heures d\u00e9marre en parall\u00e8le au triage de l’incident.<\/p>\n
L’\u00e9valuation signifie qu’il faut \u00eatre capable d’appr\u00e9cier la pertinence d’un signalement en quelques heures seulement. La vuln\u00e9rabilit\u00e9 signal\u00e9e est-elle r\u00e9ellement exploit\u00e9e activement, ou seulement exploitable th\u00e9oriquement ? Quelles versions de produits sont concern\u00e9es ? Des mesures d’att\u00e9nuation existent-elles d\u00e9j\u00e0, ou faut-il d\u00e9velopper un correctif \u00e0 chaud ? Cette capacit\u00e9 de triage exige un Software Bill of Materials (SBOM) \u00e0 jour, des environnements de reproduction test\u00e9s et une matrice d’escalade claire. Les \u00e9quipes qui ne terminent leur triage aujourd’hui qu’apr\u00e8s plusieurs jours ont besoin d’investir dans leurs processus et leurs outils.<\/p>\n
Le signalement constitue le dernier pilier et simultan\u00e9ment le point o\u00f9 l’obligation de conformit\u00e9 rencontre la r\u00e9alit\u00e9 technique. Le contenu des rapports doit \u00eatre structur\u00e9, pr\u00e9cis et juridiquement s\u00e9curis\u00e9. Le CSIRT (Computer Security Incident Response Team) n’attend pas de communication marketing, mais des indications techniques au niveau CVE (Common Vulnerabilities and Exposures), des horodatages clairs et des \u00e9tapes d’att\u00e9nuation tra\u00e7ables. Celui qui, en situation r\u00e9elle, doit faire la traduction entre le d\u00e9veloppement, le service juridique et la communication perd du temps. Les textes types et les mod\u00e8les valid\u00e9s sont des pr\u00e9paratifs obligatoires.<\/p>\n
La nomenclature logicielle (SBOM) comme pr\u00e9requis technique<\/h2>\n
Le Cyber Resilience Act (CRA) exige explicitement la cr\u00e9ation et la maintenance d’une nomenclature logicielle (Software Bill of Materials – SBOM) comme base de la gestion des vuln\u00e9rabilit\u00e9s. Une SBOM est une liste lisible par machine de tous les composants logiciels d’un produit, incluant les versions, les licences et les d\u00e9pendances. Sans SBOM, il est impossible de d\u00e9terminer rapidement quels produits sont concern\u00e9s en cas de faille de s\u00e9curit\u00e9. Le respect des d\u00e9lais de d\u00e9claration devient alors pratiquement impossible.<\/p>\n
Les deux formats de SBOM les plus courants sont SPDX et CycloneDX. Tous deux sont lisibles par machine, pris en charge par des outils et conformes aux normes de l’ENISA (Agence de l’Union europ\u00e9enne pour la cybers\u00e9curit\u00e9). Pour la mise en \u0153uvre, il est recommand\u00e9 de les g\u00e9n\u00e9rer lors du processus de compilation (build) ; les SBOM issus des d\u00e9p\u00f4ts de code sont souvent incomplets car ils ne refl\u00e8tent pas fid\u00e8lement les d\u00e9pendances binaires et les biblioth\u00e8ques transitives. Des outils comme Syft, Trivy ou les int\u00e9grations SBOM des principaux gestionnaires de paquets se sont impos\u00e9s dans les environnements de d\u00e9veloppement de la r\u00e9gion DACH (Allemagne, Autriche, Suisse) et fournissent des r\u00e9sultats valides.<\/p>\n
La maintenance continue est cruciale. Un SBOM cr\u00e9\u00e9 uniquement lors de la publication devient obsol\u00e8te en quelques jours si des d\u00e9pendances sont corrig\u00e9es. Les organisations pr\u00eates pour le CRA traitent les SBOM comme des artefacts vivants, versionn\u00e9s \u00e0 chaque compilation et disponibles dans un stockage centralis\u00e9. En cas d’urgence, une simple interrogation permet alors de d\u00e9terminer en quelques minutes quelles versions de produit contiennent une biblioth\u00e8que affect\u00e9e, condition pr\u00e9alable \u00e0 une notification rapide.<\/p>\n
Calendrier : \u00e9ch\u00e9ances et obligations<\/h2>\n\n
Ce que l’obligation de signalement du CRA implique concr\u00e8tement \u00e0 compter de septembre 2026<\/h2>\n
Le Cyber Resilience Act (CRA) constitue le premier r\u00e8glement europ\u00e9en relatif \u00e0 la cybers\u00e9curit\u00e9 des produits. Il vise les fabricants, les importateurs et les distributeurs de produits comportant des \u00e9l\u00e9ments num\u00e9riques – c’est-\u00e0-dire pratiquement tout ce qui contient un logiciel ou est connect\u00e9 en r\u00e9seau. Sont concern\u00e9s les \u00e9diteurs de logiciels classiques tout comme les fabricants de mat\u00e9riel disposant de syst\u00e8mes embarqu\u00e9s, les fournisseurs d’appareils m\u00e9nagers connect\u00e9s, de capteurs industriels, de passerelles IoT et de produits b\u00e9n\u00e9ficiant de mises \u00e0 jour de micrologiciel (firmware). L’application compl\u00e8te est pr\u00e9vue pour le 11 d\u00e9cembre 2027, mais un bloc d’obligations essentiel entre en vigueur plus t\u00f4t : \u00e0 partir du 11 septembre 2026, les fabricants devront signaler les vuln\u00e9rabilit\u00e9s activement exploit\u00e9es et les incidents de s\u00e9curit\u00e9 graves.<\/p>\n
Cette obligation de signalement repr\u00e9sente, sur le plan op\u00e9rationnel, la partie la plus critique du CRA. Elle int\u00e8gre directement les \u00e9quipes de s\u00e9curit\u00e9 informatique dans les processus r\u00e9glementaires et cr\u00e9e une interface rigide entre la gestion des vuln\u00e9rabilit\u00e9s et la communication avec les autorit\u00e9s. Les produits mis sur le march\u00e9 apr\u00e8s la date limite rel\u00e8vent int\u00e9gralement de l’obligation de signalement. Des r\u00e8gles transitoires s’appliquent aux produits existants, mais d\u00e8s qu’une mise \u00e0 jour est d\u00e9ploy\u00e9e, le fabricant doit \u00eatre en mesure d’activer la cha\u00eene de signalement du CRA.<\/p>\n
L’Office f\u00e9d\u00e9ral de la s\u00e9curit\u00e9 des technologies de l’information (BSI) a pr\u00e9cis\u00e9, dans le cadre de son initiative de conseil sur le CRA, qu’il s’agit d’obligations de signalement op\u00e9rationnelles et non de simple documentation de conformit\u00e9 formelle. Les d\u00e9lais sont stricts. Les destinataires sont clairement d\u00e9finis. Le contenu des rapports est exigeant, tant techniquement que sur le fond. Un rapport standard pilot\u00e9 par le marketing ne suffit pas – il faut fournir des indications pr\u00e9cises sur les produits concern\u00e9s, les exploits, le statut des mesures d’att\u00e9nuation et la disponibilit\u00e9 des correctifs.<\/p>\n
D\u00e9finition<\/p>\n
Une vuln\u00e9rabilit\u00e9 activement exploit\u00e9e<\/strong> au sens du CRA est une faille pour laquelle existent des indices document\u00e9s d’une exploitation r\u00e9elle – que ce soit via le renseignement sur les menaces (Threat Intelligence), un incident au sein de sa propre client\u00e8le ou un signalement externe v\u00e9rifi\u00e9. La simple existence d’une preuve de concept (Proof-of-Concept) ne suffit pas ; ce qui est d\u00e9terminant, c’est la preuve de l’utilisation contre un syst\u00e8me en production.<\/p>\n<\/div>\n Les trois d\u00e9lais du CRA (Cyber Resilience Act) pour les vuln\u00e9rabilit\u00e9s activement exploit\u00e9es s’encha\u00eenent et contraignent les \u00e9quipes de s\u00e9curit\u00e9 \u00e0 adopter une routine d’escalade clairement cadenc\u00e9e. Le chronom\u00e8tre commence \u00e0 tourner d\u00e8s que le fabricant a connaissance de l’exploitation active. \u00c0 partir de ce moment, il reste 24 heures pour une Early Warning (alerte pr\u00e9coce), qui contient les informations fondamentales sur la vuln\u00e9rabilit\u00e9, le produit concern\u00e9 et l’\u00e9tat des connaissances. L’Early Warning n’est pas une d\u00e9claration compl\u00e8te, mais un signal d’alerte pr\u00e9coce destin\u00e9 aux autorit\u00e9s.<\/p>\n Dans les 72 heures suivant cette m\u00eame prise de connaissance, la d\u00e9claration compl\u00e8te doit suivre. Elle contient des informations sur la nature de la vuln\u00e9rabilit\u00e9, les versions de produits concern\u00e9es, les premi\u00e8res recommandations d’att\u00e9nuation et l’\u00e9tat actuel de la gestion de l’incident. Quiconque ne respecte pas ce cr\u00e9neau de 72 heures enfreint l’une des obligations centrales de conformit\u00e9 du CRA. La cons\u00e9quence pratique est que les processus de r\u00e9ponse aux incidents doivent, d\u00e8s le premier jour ouvrable suivant la d\u00e9couverte, non seulement fonctionner techniquement, mais aussi \u00eatre pr\u00eats \u00e0 d\u00e9clarer sur le plan r\u00e9glementaire.<\/p>\n La troisi\u00e8me \u00e9tape est le rapport final. Pour les vuln\u00e9rabilit\u00e9s activement exploit\u00e9es, un d\u00e9lai de 14 jours s’applique \u00e0 compter de la disponibilit\u00e9 d’une mesure corrective – c’est-\u00e0-dire \u00e0 partir du moment o\u00f9 le correctif peut \u00eatre d\u00e9ploy\u00e9. Pour les incidents de s\u00e9curit\u00e9 graves, cette p\u00e9riode est \u00e9tendue \u00e0 un mois. Le rapport final documente la cause racine, les mesures prises, l’\u00e9tat du d\u00e9ploiement du correctif et les enseignements pour les futures versions du produit. Il constitue la base des audits ult\u00e9rieurs men\u00e9s par l’ENISA et les autorit\u00e9s nationales.<\/p>\n Les d\u00e9clarations au titre du Cyber Resilience Act (CRA) transitent centralement par la CRA Single Reporting Platform – un syst\u00e8me de d\u00e9claration g\u00e9r\u00e9 par l’ENISA qui pr\u00e9voit une saisie unique. Le fabricant adresse formellement la d\u00e9claration au Computer Security Incident Response Team (CSIRT) de l’\u00c9tat membre de son si\u00e8ge social. En Allemagne, l’autorit\u00e9 comp\u00e9tente est le BSI (Bundesamt f\u00fcr Sicherheit in der Informationstechnik) ou le CERT-Bund. L’information est transmise en parall\u00e8le \u00e0 l’ENISA, sauf dans des cas d’exception clairement d\u00e9finis pr\u00e9sentant des int\u00e9r\u00eats de s\u00e9curit\u00e9 particuliers.<\/p>\n Pour les entreprises disposant de plusieurs sites de production ou de filiales dans diff\u00e9rents \u00c9tats membres de l’UE, la r\u00e8gle du si\u00e8ge social est d\u00e9terminante. Elle d\u00e9finit quel CSIRT est comp\u00e9tent, quelles directives nationales s’appliquent et qui doit \u00eatre contact\u00e9 en cas de questions. Les conglom\u00e9rats aux structures mixtes doivent documenter proprement cette attribution et clarifier au sein de l’organisation qui d\u00e9clenche la d\u00e9claration en cas d’urgence. Un simple responsable produit sans mandat pour la communication avec les autorit\u00e9s \u00e9chouera face \u00e0 la r\u00e9alit\u00e9 du CRA.<\/p>\n Au sein de l’entreprise, la d\u00e9claration CRA n\u00e9cessite une responsabilit\u00e9 clairement d\u00e9finie. Elle r\u00e9side typiquement au sein du Product Security Incident Response Team (PSIRT), en lien direct avec le bureau du CISO (Chief Information Security Officer). Ceux qui ne disposent pas encore d’un PSIRT doivent mettre en place cette fonction avant la date limite. L’alternative consiste \u00e0 contraindre les \u00e9quipes de d\u00e9veloppement ad hoc \u00e0 la proc\u00e9dure de d\u00e9claration – ce qui ne s’adapte pas \u00e0 l’\u00e9chelle et \u00e9chouera face aux d\u00e9lais de 24 heures. La question des ressources humaines est au moins aussi importante que la pr\u00e9paration technique.<\/p>\n Un processus conforme au Cyber Resilience Act (CRA) repose sur trois piliers : la d\u00e9tection, l’\u00e9valuation et le signalement. La d\u00e9tection signifie que le fabricant identifie pr\u00e9cocement l’exploitation active – gr\u00e2ce \u00e0 la surveillance de ses propres produits, \u00e0 l’analyse de flux de Threat Intelligence, aux canaux de divulgation coordonn\u00e9e des vuln\u00e9rabilit\u00e9s (CVD) et \u00e0 l’int\u00e9gration aux structures des ISAC (Information Sharing and Analysis Centers). Un fabricant qui r\u00e9agit uniquement aux plaintes de clients se trouve en position d\u00e9savantageuse, car il atteint tardivement le seuil de connaissance et que l’horloge des 24 heures d\u00e9marre en parall\u00e8le au triage de l’incident.<\/p>\n L’\u00e9valuation signifie qu’il faut \u00eatre capable d’appr\u00e9cier la pertinence d’un signalement en quelques heures seulement. La vuln\u00e9rabilit\u00e9 signal\u00e9e est-elle r\u00e9ellement exploit\u00e9e activement, ou seulement exploitable th\u00e9oriquement ? Quelles versions de produits sont concern\u00e9es ? Des mesures d’att\u00e9nuation existent-elles d\u00e9j\u00e0, ou faut-il d\u00e9velopper un correctif \u00e0 chaud ? Cette capacit\u00e9 de triage exige un Software Bill of Materials (SBOM) \u00e0 jour, des environnements de reproduction test\u00e9s et une matrice d’escalade claire. Les \u00e9quipes qui ne terminent leur triage aujourd’hui qu’apr\u00e8s plusieurs jours ont besoin d’investir dans leurs processus et leurs outils.<\/p>\n Le signalement constitue le dernier pilier et simultan\u00e9ment le point o\u00f9 l’obligation de conformit\u00e9 rencontre la r\u00e9alit\u00e9 technique. Le contenu des rapports doit \u00eatre structur\u00e9, pr\u00e9cis et juridiquement s\u00e9curis\u00e9. Le CSIRT (Computer Security Incident Response Team) n’attend pas de communication marketing, mais des indications techniques au niveau CVE (Common Vulnerabilities and Exposures), des horodatages clairs et des \u00e9tapes d’att\u00e9nuation tra\u00e7ables. Celui qui, en situation r\u00e9elle, doit faire la traduction entre le d\u00e9veloppement, le service juridique et la communication perd du temps. Les textes types et les mod\u00e8les valid\u00e9s sont des pr\u00e9paratifs obligatoires.<\/p>\n Le Cyber Resilience Act (CRA) exige explicitement la cr\u00e9ation et la maintenance d’une nomenclature logicielle (Software Bill of Materials – SBOM) comme base de la gestion des vuln\u00e9rabilit\u00e9s. Une SBOM est une liste lisible par machine de tous les composants logiciels d’un produit, incluant les versions, les licences et les d\u00e9pendances. Sans SBOM, il est impossible de d\u00e9terminer rapidement quels produits sont concern\u00e9s en cas de faille de s\u00e9curit\u00e9. Le respect des d\u00e9lais de d\u00e9claration devient alors pratiquement impossible.<\/p>\n Les deux formats de SBOM les plus courants sont SPDX et CycloneDX. Tous deux sont lisibles par machine, pris en charge par des outils et conformes aux normes de l’ENISA (Agence de l’Union europ\u00e9enne pour la cybers\u00e9curit\u00e9). Pour la mise en \u0153uvre, il est recommand\u00e9 de les g\u00e9n\u00e9rer lors du processus de compilation (build) ; les SBOM issus des d\u00e9p\u00f4ts de code sont souvent incomplets car ils ne refl\u00e8tent pas fid\u00e8lement les d\u00e9pendances binaires et les biblioth\u00e8ques transitives. Des outils comme Syft, Trivy ou les int\u00e9grations SBOM des principaux gestionnaires de paquets se sont impos\u00e9s dans les environnements de d\u00e9veloppement de la r\u00e9gion DACH (Allemagne, Autriche, Suisse) et fournissent des r\u00e9sultats valides.<\/p>\n La maintenance continue est cruciale. Un SBOM cr\u00e9\u00e9 uniquement lors de la publication devient obsol\u00e8te en quelques jours si des d\u00e9pendances sont corrig\u00e9es. Les organisations pr\u00eates pour le CRA traitent les SBOM comme des artefacts vivants, versionn\u00e9s \u00e0 chaque compilation et disponibles dans un stockage centralis\u00e9. En cas d’urgence, une simple interrogation permet alors de d\u00e9terminer en quelques minutes quelles versions de produit contiennent une biblioth\u00e8que affect\u00e9e, condition pr\u00e9alable \u00e0 une notification rapide.<\/p>\nL’horloge 24-72-14 : les cha\u00eenes de signalement en d\u00e9tail<\/h2>\n
Qui d\u00e9clare au sein de l’entreprise et vers qui ?<\/h2>\n
Ce qu’un processus de r\u00e9ponse aux incidents pr\u00eat pour le CRA doit accomplir<\/h2>\n
La nomenclature logicielle (SBOM) comme pr\u00e9requis technique<\/h2>\n
Calendrier : \u00e9ch\u00e9ances et obligations<\/h2>\n
![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/03\/pexels-30965500-cisco-fmc-zero-day-250x167.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/03\/supply-chain-glassworm-2026-250x167.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/03\/pexels-279810-privileged-access-management-250x167.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-data-act-durchfuehrungsgesetz-iot-herste-60577565-250x141.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-valkey-9-redis-fork-18-monate-cloud-cach-69791755.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-ki-governance-2026-nur-14-prozent-haben-18715512-250x167.jpg\")
<\/span>