Cyber Resilience Act : signaler les vulnérabilités depuis Jira

Depuis le 11 septembre 2026, les fabricants de produits comportant des éléments numériques vendus dans l’Union doivent signaler les vulnérabilités activement exploitées et les incidents graves en quelques heures, pas en quelques semaines. La plupart des équipes logicielles suivent déjà leurs vulnérabilités dans Jira. Voici ce que le Cyber Resilience Act ajoute, et comment tenir les délais depuis vos tickets.

Ce que demande l’article 14

Le Cyber Resilience Act (règlement (UE) 2024/2847) s’applique en deux temps : les obligations de signalement de l’article 14 depuis le 11 septembre 2026, le reste du règlement à partir du 11 décembre 2027. Le signalement vaut aussi pour les produits déjà sur le marché. Deux événements sont à signaler au CSIRT national et à l’ENISA, par la plateforme unique de signalement de l’ENISA :

• Une vulnérabilité activement exploitée dans votre produit.
• Un incident grave qui touche la sécurité de votre produit.

Les trois délais

Ils partent tous du moment où vous avez connaissance de l’événement : ce moment doit donc être enregistré.

1. Alerte précoce : 24 heures. Un court avis signalant l’événement.
2. Notification : 72 heures. Ce que vous savez, la gravité et les premières mesures.
3. Rapport final. Pour une vulnérabilité, au plus tard 14 jours après la mise à disposition d’un correctif ou d’une mesure d’atténuation. Pour un incident grave, un mois après la notification.

Vous devez aussi informer les utilisateurs du produit, et publier un avis de sécurité dès qu’un correctif existe.

Ce que Jira fait déjà

Les outils d’analyse comme Snyk, Dependabot, Mend ou Trivy créent des tickets avec le composant, la CVE et une gravité. La détection est couverte. Jira ne dit pas si la vulnérabilité est à signaler, quand le délai de 24 heures a commencé, quels produits et versions contiennent le composant, ni ce que vous avez envoyé à l’ENISA et quand.

Les erreurs à éviter

• Ne pas dater la prise de connaissance. Sans elle, personne ne peut montrer que les délais ont été tenus.
• Ne pas savoir où un composant est utilisé. Gardez un SBOM par version sur le marché pour répondre en quelques minutes.
• Rédiger les rapports de mémoire. Préparez-les à partir du dossier, et gardez la référence donnée par l’ENISA.
• Des preuves éparpillées dans les e-mails et les messageries. Le règlement attend que la documentation technique, rapports compris, soit conservée au moins dix ans.

Pas à pas avec Clearlane CRA

1. Ouvrez le panneau CRA sur le ticket créé par l’outil d’analyse. Le composant, la CVE et les versions touchées y sont lus, et les produits dont le SBOM contient le composant sont proposés.
2. Qualifiez le dossier par une signature : activement exploitée ou non, et depuis quand vous le savez. Les trois délais démarrent.
3. Copiez les champs préparés dans la plateforme de l’ENISA, puis enregistrez l’heure d’envoi et la référence reçue. L’appli n’envoie jamais rien à votre place.
4. Enregistrez le correctif, l’information des utilisateurs et l’avis de sécurité, avec un fichier CSAF joint au ticket.
5. Clôturez par une signature et gardez le dossier de preuve PDF avec votre documentation technique.

Clearlane CRA aide les fabricants à répondre aux exigences de signalement du Cyber Resilience Act ; votre propre analyse reste nécessaire. Voir comment fonctionne Clearlane CRA →