Cyber Resilience Act : signaler une faille exploitée en 24 h

Le calendrier du CRA en deux dates

Le règlement (UE) 2024/2847, dit Cyber Resilience Act, s'applique en deux temps :

Date	Ce qui devient obligatoire
11 septembre 2026	Signalement des vulnérabilités activement exploitées et des incidents graves (article 14), y compris pour les produits mis sur le marché avant cette date
11 décembre 2027	Exigences essentielles de cybersécurité, dossier technique, évaluation de la conformité, déclaration UE de conformité et marquage CE

Les sanctions prévues pour le non-respect des exigences essentielles et des obligations des fabricants peuvent atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.

Qui est concerné

Le règlement vise les produits comportant des éléments numériques mis à disposition sur le marché de l'Union : logiciels vendus, micrologiciels, objets connectés, équipements industriels avec une partie logicielle, composants logiciels distribués séparément. Les services purement en ligne relèvent en principe d'autres textes, notamment NIS 2.

C'est le fabricant qui porte l'obligation de signalement, quelle que soit sa taille. Une PME qui vend un automate, une passerelle, un logiciel de supervision installé chez ses clients ou un boîtier connecté est concernée.

Les trois délais de l'article 14

Étape	Vulnérabilité activement exploitée	Incident grave
Alerte précoce	24 h après la prise de connaissance	24 h
Notification	72 h	72 h
Rapport final	14 jours après la mise à disposition d'une mesure corrective ou d'atténuation	1 mois après la notification

Le signalement se fait à la fois au CSIRT coordonnateur et à l'ENISA, par la plateforme unique de signalement. En France, l'ANSSI est le CSIRT national. Le fabricant doit aussi informer les utilisateurs concernés de la vulnérabilité et des mesures à prendre.

Quand le délai de 24 heures commence-t-il ?

Le délai court à partir du moment où le fabricant a connaissance de la vulnérabilité activement exploitée, c'est-à-dire quand il a acquis un degré raisonnable de certitude après une première évaluation. Trois conséquences pratiques :

Notez l'heure honnêtement. C'est elle qui fait courir tous les délais. Une organisation qui « découvre » systématiquement les failles le lundi matin s'expose à des questions.
Un vendredi soir compte. Les 24 heures ne s'arrêtent pas le week-end. Il faut une personne habilitée à signaler, et une suppléante.
L'alerte précoce peut être incomplète. Son but est de prévenir vite ; la notification à 72 heures et le rapport final complètent.

Le vrai problème : savoir à temps

Pour une équipe de cinq à cinquante personnes, la difficulté n'est pas de remplir le formulaire. C'est de savoir, le jour même, qu'une bibliothèque embarquée dans une version livrée il y a dix-huit mois vient d'entrer dans la liste des vulnérabilités exploitées. Cela suppose trois choses.

1. Une SBOM par version livrée

La nomenclature logicielle (SBOM) liste chaque composant et sa version. Elle se génère à partir des fichiers de verrouillage (package-lock.json, packages.lock.json, poetry.lock, Cargo.lock, go.sum…) et, pour un micrologiciel, à partir de l'outil de construction (Yocto, Buildroot, Syft). Les formats de référence sont CycloneDX et SPDX.

Le point qui piège : il faut la SBOM de chaque version encore utilisée chez les clients, pas seulement de la branche principale. Une faille corrigée depuis longtemps dans le code actuel peut être exploitée sur la version installée.

2. Un croisement quotidien avec les failles exploitées

Une base comme OSV donne les vulnérabilités connues par composant et par version. Le catalogue KEV de la CISA liste celles qui sont activement exploitées, ce qui correspond exactement à la notion du CRA. Croiser chaque jour les SBOM des versions livrées avec ces deux sources suffit à déclencher l'alerte au bon moment.

3. Un triage documenté

Toutes les vulnérabilités d'un composant ne touchent pas le produit : fonction non utilisée, composant présent seulement à la compilation, configuration qui l'empêche. Il faut l'écrire, avec une justification. Les formats VEX (CycloneDX VEX, OpenVEX) servent à ça, et c'est exactement ce qu'un auditeur demandera en 2027.

Une organisation minimale qui tient

Quoi	Qui	Quand
SBOM générée et archivée	la chaîne de build	à chaque version publiée
Croisement OSV et KEV	un script ou un outil planifié	chaque jour
Triage d'un nouveau constat	le responsable technique du produit	sous 4 heures ouvrées
Alerte précoce sur la plateforme ENISA	personne habilitée, et sa suppléante	sous 24 heures
Information des utilisateurs	responsable produit	dès que la mesure d'atténuation est connue
Rapport final	responsable technique	14 jours après le correctif

Écrivez cette procédure sur une page, désignez les personnes, et faites un exercice à blanc : prenez une vulnérabilité réelle du catalogue KEV, faites comme si elle touchait votre produit, et chronométrez.

Ce qui arrive le 11 décembre 2027

À partir de cette date, chaque produit devra satisfaire les exigences essentielles de l'annexe I (sécurité dès la conception, mises à jour de sécurité pendant la période de support, gestion des vulnérabilités), disposer d'un dossier technique (annexe VII) et d'une déclaration UE de conformité. Les SBOM et le registre de triage tenus dès maintenant en sont la base : un fabricant qui s'organise pour l'article 14 a fait une bonne partie du travail.

Outiller sans envoyer son code

Suivi CRA fait ces trois étapes sur votre poste : SBOM CycloneDX depuis dix formats de verrouillage (et fusion avec la SBOM du micrologiciel), croisement OSV et KEV, registre de triage, calcul des échéances 24 h et 72 h et brouillons de signalement, dossier annexe VII. Votre code ne sort pas. Une édition libre (MIT) permet de commencer sans rien payer. L'outil ne rend pas un produit conforme et n'envoie rien à l'ENISA : il produit et tient à jour les preuves.

Cyber Resilience Act : signaler une vulnérabilité exploitée en 24 heures