Annexe I du CRA : les exigences essentielles, une par une

L’annexe I du Cyber Resilience Act liste ce que tout produit comportant des éléments numériques doit atteindre pour être vendu dans l’UE à partir du 11 décembre 2027. Elle a deux parties : la partie I, les propriétés de sécurité du produit lui-même, et la partie II, la façon dont le fabricant gère ses vulnérabilités pendant la période d’assistance.

Les exigences sont écrites en termes de résultats, pas de techniques. Les normes harmonisées décriront des façons reconnues de les atteindre ; tant qu’elles ne sont pas publiées au Journal officiel, vous montrez la conformité en expliquant les solutions retenues dans votre documentation technique. Servez-vous de ce guide comme d’une liste de contrôle : pour chaque exigence, notez comment votre produit la respecte, ou pourquoi elle ne s’applique pas.

Commencez par l’analyse des risques

L’article 13 vous demande d’évaluer d’abord les risques de cybersécurité du produit, et de tenir cette évaluation à jour pendant la période d’assistance. C’est elle qui décide comment chaque exigence de la partie I s’applique à votre produit : toute la liste a) à m) est introduite par « sur la base de l’évaluation des risques de cybersécurité » et « le cas échéant ». Une exigence que vous jugez non applicable doit être clairement justifiée dans l’évaluation des risques elle-même, qui fait partie du dossier technique.

Partie I : les propriétés de sécurité du produit

La première exigence est générale : les produits sont conçus, développés et fabriqués de manière à garantir un niveau de cybersécurité approprié au regard des risques. Ensuite, sur la base de l’évaluation des risques et le cas échéant, le produit doit :

a) Être livré sans vulnérabilité exploitable connue

Aucune vulnérabilité connue et exploitable ne doit subsister au moment de la mise sur le marché. En pratique : analysez les composants de chaque version face aux bases de vulnérabilités avant de livrer, et notez pourquoi un résultat restant n’est pas exploitable (une déclaration VEX).

b) Être sûr par défaut

Le produit est livré avec une configuration sûre, sauf accord contraire avec un utilisateur professionnel pour un produit sur mesure, et l’utilisateur peut le ramener à son état d’origine. Pas de mot de passe par défaut commun à tous les appareils, services inutiles coupés, interfaces de débogage fermées.

c) Recevoir des mises à jour de sécurité

Les vulnérabilités doivent pouvoir être corrigées par des mises à jour de sécurité, y compris, le cas échéant, des mises à jour automatiques installées dans un délai raisonnable et activées par défaut, avec un mécanisme clair et simple pour les désactiver. Les utilisateurs sont prévenus quand une mise à jour est disponible et peuvent la reporter un temps.

d) Protéger contre les accès non autorisés

Authentification, gestion des identités et des accès adaptées au produit, et un signalement en cas d’accès non autorisé possible. Pensez protection contre les attaques par force brute, identifiants propres à chaque appareil, moindre privilège.

e) Protéger la confidentialité

Les données que le produit stocke, transmet ou traite, personnelles ou non, restent confidentielles : chiffrement au repos et en transit avec des algorithmes actuels, et d’autres moyens techniques au besoin.

f) Protéger l’intégrité

Données, commandes, programmes et configuration sont protégés contre toute manipulation ou modification que l’utilisateur n’a pas autorisée, et les altérations sont signalées. Micrologiciel et mises à jour signés, démarrage vérifié, configuration contrôlée.

g) Minimiser les données

Seules les données adéquates, pertinentes et limitées à ce que demande la destination du produit sont traitées.

h) Garder les fonctions essentielles disponibles

Les fonctions essentielles et de base restent disponibles, y compris après un incident, avec de la résilience et des mesures contre les attaques par déni de service.

i) Ne pas nuire aux autres

Le produit limite l’effet négatif, le sien ou celui des appareils qui y sont connectés, sur la disponibilité des services fournis par d’autres appareils ou réseaux. Un appareil compromis ne doit pas devenir facilement un maillon d’un botnet qui inonde les autres.

j) Réduire la surface d’attaque

Moins d’interfaces exposées, moins de ports ouverts, moins de composants : la surface d’attaque, interfaces externes comprises, est limitée à ce dont le produit a besoin.

k) Réduire l’impact des incidents

Des mécanismes et techniques d’atténuation de l’exploitation : langages sûrs pour la mémoire ou durcissement, isolation, séparation des privilèges, pour qu’une seule faille ne livre pas tout.

l) Enregistrer les événements de sécurité

Le produit fournit des informations utiles à la sécurité en enregistrant et en surveillant l’activité interne pertinente, comme l’accès aux données, services ou fonctions et leur modification, avec une possibilité de refus pour l’utilisateur.

m) Permettre d’effacer et de transférer ses données

Les utilisateurs peuvent supprimer toutes leurs données et tous leurs réglages de façon sûre, simple et définitive, et, quand les données peuvent être transférées vers d’autres produits ou systèmes, le faire de façon sûre.

Partie II : la gestion des vulnérabilités

Ces exigences s’appliquent à la mise sur le marché puis pendant toute la période d’assistance. Les fabricants doivent :

1. Savoir ce qu’il y a dedans

Recenser et documenter les vulnérabilités et les composants du produit, notamment en établissant une nomenclature des logiciels dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de niveau supérieur. Voir Qu’est-ce qu’un SBOM ? et le SBOM pour le CRA.

2. Corriger sans délai

Traiter et corriger les vulnérabilités sans délai, au regard des risques qu’elles présentent, notamment en fournissant des mises à jour de sécurité. Quand c’est techniquement possible, les mises à jour de sécurité sont fournies séparément des mises à jour fonctionnelles, pour que l’utilisateur n’ait pas à prendre de nouvelles fonctions pour obtenir un correctif.

3. Tester régulièrement

Appliquer des tests et des revues efficaces et réguliers de la sécurité du produit : revue de code, analyse des dépendances, tests d’intrusion, fuzzing, choisis selon les risques.

4. Publier ce qui a été corrigé

Une fois une mise à jour de sécurité disponible, partager et rendre publiques les informations sur les vulnérabilités corrigées : une description, les produits touchés, l’impact et la gravité, et des informations claires pour aider les utilisateurs à y remédier. Dans des cas dûment justifiés, quand les risques de la publication l’emportent sur ses avantages, elle peut attendre que les utilisateurs aient pu appliquer le correctif. Les avis de sécurité lisibles par machine (CSAF) sont le moyen habituel.

5. Avoir une politique de divulgation

Mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités. Notre générateur de politique de divulgation gratuit en rédige une à partir de vos réponses.

6. Être joignable

Faciliter le partage d’informations sur les vulnérabilités possibles du produit et de ses composants tiers, notamment en donnant une adresse de contact pour les signaler. Un fichier security.txt est la façon standard de la publier.

7. Distribuer les mises à jour de façon sûre

Prévoir des mécanismes de distribution sûre des mises à jour, pour que les vulnérabilités soient corrigées ou atténuées à temps et, le cas échéant pour les mises à jour de sécurité, automatiquement.

8. Fournir les correctifs gratuitement, et les expliquer

Diffuser les mises à jour de sécurité sans délai et, sauf accord contraire avec un utilisateur professionnel pour un produit sur mesure, gratuitement, avec des messages d’information qui disent aux utilisateurs ce qu’ils doivent savoir et faire.

Comment montrer que vous les respectez

Pour chaque exigence, la documentation technique (annexe VII) doit dire comment elle est respectée : le choix de conception, le test, la norme ou le processus, et où se trouve la preuve. Tenez-la par produit et par version :

• l’évaluation des risques et ses conclusions, exigence par exigence ;
• le SBOM de chaque version, et les vulnérabilités trouvées avec vos décisions ;
• les rapports de tests ;
• la politique de divulgation, le point de contact et les avis publiés ;
• la façon dont les mises à jour sont construites, signées et distribuées.

Les normes harmonisées simplifieront tout cela une fois publiées : les suivre donne une présomption de conformité. D’ici là, les projets de normes de la série EN 40000, comme le prEN 40000-1-3 sur la gestion des vulnérabilités, montrent bien ce que regarderont les évaluateurs.

Ce que fait Provetry

Provetry couvre pour vous l’essentiel de la partie II : un SBOM pour chaque version, le rapprochement quotidien avec les vulnérabilités nouvelles et exploitées, les décisions VEX, votre politique de divulgation et votre security.txt, les avis CSAF et l’horloge de signalement. Son dossier de conformité parcourt la partie I exigence par exigence et garde les réponses dans votre documentation technique.

Ce guide est une information générale, pas un conseil juridique.

Sources

• Règlement (UE) 2024/2847, le Cyber Resilience Act, article 13, annexe I et annexe VII
• Commission européenne : Cyber Resilience Act
• CEN-CENELEC : normalisation du Cyber Resilience Act