Accueil / Règlement UE
Règlement UE
Cyber Resilience Act
Le CRA concerne les produits comportant des éléments numériques mis sur le marché de l’Union.
Effet de cette exigence
Cette règle ne se lit pas seule.
- Transferts
- Relation bilatérale
- Sources pays revues le
Hypothèses, limites et sources de cette lecture
Point de lecture
Le produit porte sa propre chronologie
Versions, composants, vulnérabilités et décisions de support doivent pouvoir être reconstruits.
- Qualification du produit et rôle économique
- Cycle de développement et maintenance
- Vulnérabilités, dépendances et support
- Documentation et preuves produit
Cycle de sécurité produit
Rendre la sécurité vérifiable de la conception jusqu’au traitement d’une vulnérabilité.
Concevoir
Exigences, architecture, menaces et choix de dépendances.
Construire
Développement, intégration, tests et traçabilité des composants.
Distribuer et maintenir
Versions, documentation, support et correctifs.
Recevoir et traiter
Signalement, qualification, coordination et décision produit.
Chemin de décision
Construire la lecture autour du produit et de ses versions
L’analyse doit suivre ce qui est mis sur le marché, maintenu et corrigé, plutôt qu’un programme cyber général détaché du cycle produit.
01Produit et rôle économique
Identifier le produit comportant des éléments numériques, les versions concernées et le rôle tenu dans sa mise à disposition sur le marché européen.
02Période de support
Définir les versions maintenues, les engagements de correctif, les dépendances et les conditions de fin de support annoncées aux utilisateurs.
03Traitement des vulnérabilités
Relier réception d’un signalement, qualification, décision, correction, coordination et communication aux équipes effectivement responsables.
04Dossier par version
Conserver architecture, composants, tests, SBOM, décisions de risque, documentation et preuves de correctif pour la version réellement distribuée.
Dossier de sécurité produit
Les traces qui doivent suivre le produit et ses versions.
Questions à traiter
- La qualification CRA de votre produit et votre rôle économique
- Votre processus de gestion et divulgation des vulnérabilités
- Vos SBOM et la maîtrise de vos dépendances
- Vos périodes de support et votre politique de mise à jour
Éléments qui étayent la réponse
- Inventaire produits/versions avec statut de support
- Canal de divulgation opérationnel et journal de traitement
- SBOM générées par version publiée
- Documentation technique et décisions de correctifs datées
Confusions à éviter
- Attendre l’échéance réglementaire alors que les acheteurs demandent déjà
- Publier un canal de divulgation sans processus derrière
- Confondre SBOM générée une fois et SBOM maintenue
- Promettre un support produit sans capacité d’ingénierie durable
Dossier d’assurance, PR-046Exemple de démonstration
Attente du marchéSBOM disponible pour chaque version supportéeConstat
Réponse envisagée« SBOM disponible sur demande »Constat
État réelSBOM générée une fois, jamais reliée aux versions publiéesConstat
Divergence observéeLa SBOM ne correspond plus aux versions livréesÉcart
ImpactDifficile à défendre lors de l’examen du produitÉcart
ActionGénérer la SBOM dans la chaîne d’intégration et l’attacher à chaque versionDécision
Lecture des couleursConstat factuelÉcart ou risqueDécision ou action
Démonstration
Suivre une vulnérabilité jusqu’à la version effectivement distribuée.
Le cas conserve le composant, les versions affectées, la décision de correction et les éléments du dossier produit qui devront être actualisés.
Comprendre la qualification d’une preuve →Appliquer cette lecture
Délimiter le produit, les versions et le rôle de l’entreprise.
La liste des produits, les versions supportées et le rôle tenu sur le marché permettent d’identifier le cycle documentaire et technique à examiner.