Modèle d'avis de vulnérabilité CRA (DOCX & PDF gratuits)

Modèle d'avis de vulnérabilité CRA

Un modèle d'avis de vulnérabilité CRA donne à votre équipe sécurité une structure reproductible pour les divulgations publiques que le Cyber Resilience Act exige dès que vous corrigez une vulnérabilité. À partir du 11 septembre 2026, les fabricants de produits comportant des éléments numériques sont soumis à des obligations de notification contraignantes au titre du règlement (UE) 2024/2847 — et à partir de l'application complète en décembre 2027, la publication d'informations sur les vulnérabilités corrigées cesse d'être une bonne pratique pour devenir une condition d'accès au marché. Ce modèle gratuit d'avis de sécurité est livré en DOCX, PDF et en fichier Markdown lisible par un agent IA (fichiers téléchargeables en anglais), avec tous les champs nécessaires à un avis conforme plus un exemple entièrement rempli.

Un avis de vulnérabilité conforme au CRA doit décrire la vulnérabilité corrigée, identifier le produit et les versions affectés, et indiquer aux utilisateurs les mesures à prendre (annexe I, partie II, points 4 et 8 du règlement (UE) 2024/2847). Un avis complet ajoute un identifiant CVE ou EUVD, un score et un vecteur CVSS v4.0, les versions corrigées, les mesures d'atténuation ou de contournement, le statut d'exploitation, une chronologie de divulgation, un journal de mises à jour et un contact sécurité. Si la vulnérabilité est activement exploitée, une horloge réglementaire distincte court en parallèle : alerte précoce à l'ENISA et à votre CSIRT coordinateur sous 24 heures, notification sous 72 heures et rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective (article 14).

À retenir

• Les exigences de gestion des vulnérabilités du CRA figurent à l'annexe I, partie II ; l'article 13 en fait une obligation centrale du fabricant, et l'article 14 ajoute la notification réglementaire des vulnérabilités activement exploitées.
• Deux horloges différentes : l'avis public est dû dès qu'une mise à jour de sécurité est disponible ; la notification de l'article 14 (24 h / 72 h / 14 jours via la plateforme unique de notification de l'ENISA) ne se déclenche que pour les vulnérabilités activement exploitées.
• Les avis devraient porter à la fois un identifiant CVE et un identifiant EUVD — la base de données européenne des vulnérabilités de l'ENISA est désormais la référence native de l'UE pour les clients comme pour les CSIRT.
• L'article 14(8) vous impose d'informer les utilisateurs concernés, « le cas échéant dans un format structuré et lisible par machine » — les champs de ce modèle correspondent à CSAF 2.0, le standard OASIS d'avis lisibles par machine.
• Les amendes pour violation des articles 13/14 ou de l'annexe I atteignent 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.

Ce que contient le modèle

Le modèle reprend le jeu de champs utilisé par les équipes de sécurité produit matures et couvre tout ce que l'annexe I, partie II attend, dans l'ordre dont vos lecteurs ont besoin :

Champ	Ce qu'il capture	Pourquoi il compte
Identifiant de l'avis	Votre identifiant interne (p. ex. ACME-SA-2026-001)	Référence stable à travers les mises à jour, les e-mails et les documents CSAF
Titre	Résumé d'une ligne nommant le produit et la classe de faille	La première chose que clients et agrégateurs indexent
Identifiant CVE / EUVD	CVE-YYYY-NNNNN et EUVD-YYYY-NNNNN	Références croisées vers le NVD et l'EUVD de l'ENISA
Score + vecteur CVSS v4.0	Score numérique, niveau de gravité, chaîne de vecteur complète	Gravité objective ; pilote les SLA de correctifs des clients
Produits & versions affectés	Noms de produits, plages de versions, modèles de déploiement	L'annexe I, partie II exige que les utilisateurs puissent identifier les produits affectés
Versions corrigées	Première version corrigée par ligne affectée	La cible d'action de tout l'avis
Atténuations & contournements	Mesures provisoires lorsque le correctif est retardé	Les « mesures que les utilisateurs peuvent prendre » requises (annexe I, partie II, point 8)
Impact	Ce qu'un attaquant peut obtenir, préconditions	Permet aux clients de mener leur propre analyse de risque
Statut d'exploitation	Aucune connue / PoC publié / exploitée dans la nature	Détermine si la notification de l'article 14 est déclenchée
Chronologie	Signalement reçu → triage → correctif → dates de divulgation	Preuve d'un traitement « sans retard » ; renforce la confiance des chercheurs
Journal de mises à jour	Historique daté des révisions de l'avis	Montre que l'avis est maintenu, et non publié puis oublié
Contact & clé PGP	Adresse du contact sécurité et clé de chiffrement	L'annexe I, partie II exige une adresse de contact pour les signalements de vulnérabilités

La variante Markdown inclut en outre les définitions de champs, une échelle de gravité, une énumération des statuts d'exploitation, les états du cycle de vie d'un avis, une variante e-mail de notification aux abonnés et un exemple fictif entièrement rempli — pour que votre équipe comme vos outils d'IA puissent rédiger un avis complet à partir d'un seul fichier.

Comment utiliser le modèle

1. Triez le signalement. Consignez la date de réception, confirmez la vulnérabilité et attribuez votre identifiant d'avis interne. Demandez un identifiant CVE (via votre CNA ou MITRE) et notez l'identifiant EUVD dès son attribution.
2. Notez-la. Calculez le score de base CVSS v4.0 et enregistrez la chaîne de vecteur complète, puis renseignez honnêtement le champ statut d'exploitation — il conditionne tout ce qui suit.
3. Vérifiez le déclencheur réglementaire. Si la vulnérabilité est activement exploitée, les obligations de l'article 14 démarrent immédiatement : alerte précoce sous 24 heures via la plateforme unique de notification, notification sous 72 heures, rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective. L'avis public est un livrable distinct, sur une horloge distincte.
4. Corrigez, puis rédigez. Préparez l'avis pendant que le correctif est en cours, mais ne publiez qu'une fois la mise à jour de sécurité disponible — c'est le point de divulgation auquel l'annexe I, partie II s'ancre. Coordonnez l'embargo avec le rapporteur dans le cadre de votre politique de divulgation coordonnée des vulnérabilités (CVD).
5. Notifiez les abonnés, puis publiez. Envoyez l'e-mail de notification aux abonnés (inclus dans le modèle) aux contacts sécurité et aux abonnés du Trust Center au moment de la publication ou juste avant, puis publiez l'avis. L'article 14(8) impose par ailleurs d'informer les utilisateurs concernés des vulnérabilités activement exploitées et des mesures d'atténuation — le CSIRT peut le faire à votre place, publiquement, si vous y manquez.
6. Tenez le journal de mises à jour. Chaque changement matériel — nouvelles versions affectées, exploitation observée, atténuations révisées — reçoit une entrée datée. Ne clôturez l'avis que lorsque toutes les lignes supportées sont corrigées.

Obligation de notification vs avis public — la distinction qui piège les équipes

La plupart des vulnérabilités que vous corrigez ne toucheront jamais la plateforme de l'ENISA. L'article 14 couvre les vulnérabilités activement exploitées (et les incidents graves) ; l'annexe I, partie II couvre chaque vulnérabilité corrigée. Construisez votre processus de sorte que le modèle d'avis soit le chemin par défaut, avec l'escalade de l'article 14 greffée dessus lorsque des preuves d'exploitation apparaissent — et non l'inverse.

Base juridique

• Règlement (UE) 2024/2847 (Cyber Resilience Act), article 13 — les fabricants doivent gérer les vulnérabilités « conformément aux exigences de gestion des vulnérabilités énoncées à l'annexe I, partie II » pendant toute la période de support, et doivent opérer une politique de divulgation coordonnée des vulnérabilités.
• Annexe I, partie II — les exigences de gestion des vulnérabilités : identifier et documenter les vulnérabilités (y compris un SBOM couvrant au moins les dépendances de premier niveau, point 1) ; dès qu'une mise à jour de sécurité est disponible, partager et divulguer publiquement des informations sur les vulnérabilités corrigées, y compris une description et des informations permettant aux utilisateurs d'identifier le produit affecté (point 4) ; appliquer une politique CVD (point 5) ; fournir une adresse de contact pour les signalements de vulnérabilités ; et diffuser sans retard des mises à jour de sécurité gratuites, accompagnées de messages d'avis contenant les informations pertinentes et les mesures que les utilisateurs peuvent prendre (point 8).
• Article 14 — notification des vulnérabilités activement exploitées au CSIRT désigné comme coordinateur et à l'ENISA via la plateforme unique de notification établie par l'article 16 : alerte précoce sous 24 heures, notification sous 72 heures, rapport final au plus tard 14 jours après la disponibilité d'une mesure corrective. L'article 14(8) impose d'informer les utilisateurs concernés, le cas échéant dans un format structuré et lisible par machine. Ces obligations s'appliquent à partir du 11 septembre 2026 ; les obligations principales du CRA à partir du 11 décembre 2027.
• Avis lisibles par machine — le CRA ne nomme aucun format, mais CSAF 2.0 (Common Security Advisory Framework, un standard OASIS) est le standard établi pour les avis structurés, utilisé par la CISA et les grands éditeurs. Les champs de ce modèle correspondent aux propriétés de document CSAF, ce qui rend une migration ultérieure vers CSAF mécanique.
• Sanctions — le non-respect des exigences essentielles de l'annexe I ou des articles 13/14 est passible d'amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total (article 64).

Pour la vue d'ensemble des obligations du fabricant, consultez nos guides sur le Cyber Resilience Act et les articles 13 et 14 du CRA.

Royaume-Uni et Norvège/EEE

Royaume-Uni : le régime du Product Security and Telecommunications Infrastructure (PSTI) Act 2022, en vigueur depuis le 29 avril 2024, impose aux fabricants de produits connectables grand public vendus au Royaume-Uni de publier une politique de divulgation des vulnérabilités avec un contact de signalement — les champs contact, chronologie et journal de mises à jour de ce modèle y font double emploi, même si le PSTI exige aussi le document de politique et une période de mises à jour de sécurité déclarée. Norvège/EEE : le CRA est marqué comme pertinent pour l'EEE et devrait être incorporé dans l'accord sur l'EEE ; les fabricants norvégiens, islandais et liechtensteinois vendant sur le marché unique de l'UE sont de toute façon concernés en pratique, puisque le CRA s'attache aux produits mis sur le marché de l'UE.

Publiez vos avis là où vos clients regardent déjà

Un avis que personne ne voit manque son but. Orbiq Trust Updates publie vos avis de sécurité et notifications d'incident directement sur votre Trust Center, notifie automatiquement les clients abonnés et tient le journal de mises à jour daté que le CRA attend — transformant une obligation de conformité en signal de confiance visible. À lire aussi : ce qu'est un Trust Center et comment les obligations de notification d'incidents NIS2 interagissent avec la notification des clients.

---

Sources et références

1. Règlement (UE) 2024/2847 (Cyber Resilience Act) — texte intégral — Journal officiel de l'Union européenne.
2. Commission européenne — obligations de notification du CRA — la plateforme unique de notification et les délais de l'article 14.
3. Commission européenne — page politique du Cyber Resilience Act — entrée en vigueur et dates d'application.
4. ENISA — Base de données européenne des vulnérabilités (EUVD) — enregistrements de vulnérabilités de l'UE et identifiants EUVD.
5. Directive (UE) 2022/2555 (NIS2), article 12 — base juridique de la base de données européenne des vulnérabilités.
6. OASIS — Common Security Advisory Framework (CSAF) v2.0 — standard d'avis de sécurité lisibles par machine.
7. FIRST — spécification CVSS v4.0 — notation et niveaux de gravité.
8. UK Product Security and Telecommunications Infrastructure Act 2022 — régime britannique de sécurité des produits.
9. ENISA — Cyber Resilience Act Requirements Standards Mapping — correspondance entre les exigences du CRA et les standards existants.