L'annexe I partie II du Règlement (UE) 2024/2847 fixe huit obligations numérotées que tout fabricant d'un produit comportant des éléments numériques doit honorer tout au long de la période d'assistance : identification adossée au SBOM, remédiation sans retard, tests réguliers, divulgation publique des correctifs, politique de divulgation coordonnée des vulnérabilités, canal de signalement externe, distribution sécurisée des mises à jour et mises à jour de sécurité gratuites. Cette page parcourt chaque obligation et indique où s'arrête la gestion au titre de l'annexe I et où commence le signalement au titre de l'article 14.
Résumé
- L'annexe I partie II est la spécification d'ingénierie de la gestion des vulnérabilités au titre du CRA, applicable à chaque fabricant pour chaque produit comportant des éléments numériques.
- Huit obligations numérotées : identifier (avec SBOM), remédier sans retard, tester régulièrement, divulguer publiquement les vulnérabilités corrigées, opérer une politique CVD, faciliter le signalement des vulnérabilités, distribuer les mises à jour de manière sécurisée, fournir gratuitement les mises à jour de sécurité.
- La gratuité n'est pas négociable : les mises à jour de sécurité doivent être fournies gratuitement au titre de l'annexe I partie II point 8, la seule dérogation concernant les produits sur mesure destinés à des utilisateurs professionnels.
- La politique CVD est obligatoire, pas optionnelle : l'annexe I partie II point 5 fait de la divulgation coordonnée des vulnérabilités une obligation de marquage CE, pas une bonne pratique.
- La gestion des vulnérabilités s'opère tout au long de la période d'assistance définie à l'article 3(20) et à l'article 13(8) ; le minimum est de cinq ans à compter de la mise sur le marché.
- La gestion des vulnérabilités n'est pas le signalement de l'article 14 : la gestion est le processus d'ingénierie quotidien ; le signalement est la cadence 24h/72h/14j déclenchée uniquement par les vulnérabilités activement exploitées ou les incidents graves (voir signalement CRA article 14).
Les quatre points d'ancrage qui cadrent la gestion des vulnérabilités CRA : champ d'application, durée, règle de coût et plafond des sanctions.
Les huit obligations de l'annexe I partie II
L'annexe I partie II du Règlement (UE) 2024/2847 énumère huit obligations numérotées. Ce n'est pas une liste de vérification : elles décrivent un cycle de vie continu qui s'opère tout au long de la période d'assistance. Le regroupement ci-dessous les organise selon la phase opérationnelle dans laquelle chacune s'inscrit.
Points 1, 6. Identification fondée sur le SBOM des composants et des vulnérabilités connues, et canal de contact public permettant aux tiers de signaler ce que vos scanners ont manqué.
Points 2, 3. Remédiation sans retard (proportionnée à la gravité, et non un SLA fixe) et tests réguliers efficaces de la base de code et de ses dépendances.
Points 7, 8. Canal de mise à jour sécurisé (signé, authentifié, automatique lorsque c'est applicable), avec des mises à jour de sécurité dissociables des fonctionnalités et gratuites, sauf pour les produits B2B sur mesure.
Points 4, 5. Politique de divulgation coordonnée des vulnérabilités effectivement mise en place et appliquée, et avis publics dès qu'un correctif est disponible, avec une dérogation étroite « dûment justifiée » de report.
Ce que chaque obligation signifie en pratique
| # | Obligation | Ce qu'elle exige réellement |
|---|---|---|
| 1 | Identifier et documenter les vulnérabilités et les composants | Un SBOM en CycloneDX ou SPDX, couvrant au minimum les dépendances de premier niveau. Le SBOM est l'index qui rend possible la mise en correspondance avec les CVE : on ne peut pas remédier ce que l'on n'a pas catalogué. |
| 2 | Remédier sans retard, séparément des fonctionnalités | Pas de SLA fixe ; la rapidité attendue est proportionnée à la gravité. Les branches de sécurité doivent être dissociables des branches de fonctionnalités afin que les utilisateurs ne puissent pas reporter un correctif en reportant une version. |
| 3 | Tests efficaces et réguliers | Analyse statique, tests dynamiques, scan des dépendances par rapport aux flux de vulnérabilités, et tests de pénétration. « Régulier » doit correspondre au risque et au rythme d'évolution de la base de code. |
| 4 | Divulgation publique des vulnérabilités corrigées | Une fois le correctif livré, publier la description, le produit affecté, l'impact, la gravité et la remédiation. Report uniquement « dans les cas dûment justifiés » jusqu'à ce que les utilisateurs puissent appliquer le correctif. CVE plus CSAF est le support de fait. |
| 5 | Politique de divulgation coordonnée des vulnérabilités | Une politique CVD écrite et appliquée, avec canal d'entrée, SLA de réponse et conditions de divulgation. ISO/IEC 29147 et 30111 fournissent un cadre formel. |
| 6 | Faciliter le signalement externe des vulnérabilités | Une adresse de contact pour signaler les problèmes affectant le produit et ses composants tiers. security.txt au titre de la RFC 9116 satisfait à l'exigence de canal. |
| 7 | Distribution sécurisée des mises à jour | Mises à jour signées, authentifiées, automatiques lorsque c'est applicable. Les produits sans canal de mise à jour doivent en construire un ou documenter pourquoi l'automatisation n'est pas applicable. Voir mises à jour de sécurité. |
| 8 | Gratuit, avec messages d'avis | Les mises à jour de sécurité doivent être diffusées sans retard et gratuitement (seule dérogation : produits sur mesure destinés à des utilisateurs professionnels lorsque les parties en sont convenues autrement). Chaque mise à jour doit être accompagnée d'un message d'avis décrivant le problème et l'action que l'utilisateur doit entreprendre. Une barrière de maintenance payante, ou un correctif silencieux sans avis, viole le point 8. |
Gestion des vulnérabilités et période d'assistance
Les exigences de l'annexe I partie II s'appliquent tout au long de la période d'assistance définie à l'article 3(20) et requise par l'article 13(8). La période d'assistance est d'au moins cinq ans à compter de la date de mise sur le marché européen, ou la durée d'utilisation effective attendue si elle est plus courte et divulguée. La date de fin de la période d'assistance doit figurer dans les informations produit au titre de l'annexe II. Une fois la période d'assistance échue, les obligations de l'annexe I partie II cessent pour cette version du produit, mais l'obligation de conservation documentaire au titre de l'article 31 (dix ans à compter de la mise sur le marché) se poursuit. Voir période d'assistance CRA.
La gestion des vulnérabilités n'est pas le signalement de l'article 14
Le CRA distingue deux obligations qui opèrent sur des surfaces et des destinataires différents :
- La gestion des vulnérabilités au titre de l'annexe I partie II est le processus d'ingénierie : SBOM, remédiation, politique CVD, divulgation publique, mises à jour sécurisées. Elle s'applique à toutes les vulnérabilités, en permanence, tout au long de la période d'assistance. Elle est délivrée via l'organisation de sécurité produit du fabricant.
- Le signalement au titre de l'article 14 est la notification réglementaire déclenchée par une vulnérabilité activement exploitée (article 3(42)) ou un incident grave ayant un impact sur la sécurité du produit. Il est délivré via la plateforme unique de signalement ENISA selon une cadence 24h / 72h / 14j à l'ENISA et au CSIRT désigné comme coordinateur. Pour les modalités d'intégration à la SRP, voir intégration à la SRP ENISA.
Une équipe produit peut être pleinement conforme à l'annexe I partie II sans jamais déposer de rapport au titre de l'article 14, car la plupart des vulnérabilités sont remédiées avant d'être activement exploitées. L'article 14 ne se déclenche que lorsque la remédiation n'a pas encore rattrapé l'exploitation active. Voir signalement CRA article 14.
Sanctions en cas de manquement
Le non-respect des exigences essentielles de l'annexe I, y compris la gestion des vulnérabilités au titre de la partie II, relève du niveau le plus élevé des amendes administratives à l'article 64(2) : jusqu'à 15 000 000 € ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu. L'obligation s'applique à compter du 11 décembre 2027 pour les produits mis sur le marché à partir de cette date.
Foire aux questions
Le SBOM au titre de l'annexe I partie II point 1 doit-il couvrir les dépendances transitives ?
Le texte exige « au minimum les dépendances de premier niveau », ce qui constitue le plancher réglementaire. Les composants transitifs ne sont pas imposés par le point 1, mais ils le sont en pratique par le point 2 : on ne peut pas « remédier sans retard aux vulnérabilités » pour un CVE dans un composant transitif que l'on n'a jamais catalogué. La plupart des régulateurs et des clients attendent un SBOM en profondeur conforme à BSI TR-03183 ou à des orientations comparables. CycloneDX et SPDX sont tous deux qualifiés de formats « couramment utilisés et lisibles par machine ». Voir exigences SBOM CRA.
Que signifie « sans retard » en pratique pour la remédiation au titre du point 2 ?
Le CRA ne fixe pas de SLA de remédiation. « Sans retard » est proportionné au risque de cybersécurité : une vulnérabilité critique avec exploitation active dans la nature exige un correctif en quelques jours, tandis qu'un problème de faible gravité peut attendre le prochain cycle régulier. La gravité s'établit avec CVSS, s'affine avec les données de probabilité d'exploitation EPSS, et se confirme par les éléments du catalogue CISA KEV lorsque la vulnérabilité figure sur la liste des vulnérabilités activement exploitées de la CISA. Voir notation de gravité pour l'échelle opérationnelle que les autorités de surveillance du marché appliquent pour apprécier si un fabricant a remédié « sans retard ».
Les mises à jour de sécurité peuvent-elles être facturées dans certaines circonstances ?
Une seule dérogation existe : l'annexe I partie II point 8 autorise un arrangement payant pour les produits sur mesure fournis à un utilisateur professionnel lorsque le fabricant et l'utilisateur professionnel en sont convenus autrement. Pour tout autre produit, y compris l'ensemble des produits grand public et des produits SaaS ou matériels B2B standard, les mises à jour de sécurité doivent être gratuites tout au long de la période d'assistance. Conditionner un correctif de sécurité à un palier de maintenance payant constitue une violation directe du point 8 et expose le fabricant aux amendes du niveau le plus élevé au titre de l'article 64(2).
Les obligations de l'annexe I partie II se poursuivent-elles après la fin de la période d'assistance ?
Non. Les huit obligations de l'annexe I partie II s'appliquent tout au long de la période d'assistance au titre de l'article 13(8) et cessent pour cette version du produit lorsque la période d'assistance prend fin. Deux obligations survivent à la période d'assistance : l'obligation de conservation de la documentation technique au titre de l'article 31 (dix ans à compter de la mise sur le marché), et tout signalement au titre de l'article 14 déjà en cours au moment où la période a pris fin. Les nouvelles vulnérabilités découvertes après la fin de l'assistance n'ont pas à être remédiées pour cette version, mais le fabricant doit avoir publié une date de fin d'assistance claire dans les informations produit afin que les utilisateurs puissent migrer. Voir période d'assistance et divulgation de la fin d'assistance.
Quand un signalement CVD entrant devient-il un déclencheur de l'article 14 ?
Le déclencheur est « activement exploitée » au titre de l'article 3(42), pas « signalée » ni « exploitable ». Une preuve de concept fonctionnelle jointe à un signalement CVD ne constitue pas en soi un déclencheur de l'article 14 ; elle le devient lorsqu'il existe une croyance raisonnable qu'un acteur malveillant a utilisé la faille contre une cible réelle. Une fois ce seuil franchi, l'alerte précoce de 24 heures à l'ENISA et au CSIRT coordinateur démarre, suivie de la notification à 72 heures et d'un rapport final dans les 14 jours suivant la disponibilité d'une mesure corrective. Voir signalement CRA article 14.