L’exigence la plus difficile du Cyber Resilience Act n’est pas la cybersécurité

Le contenu de cette page a été traduit automatiquement par un service tiers.

La plupart des contenus publiés sur le Cyber Resilience Act de l’UE (CRA) le présentent comme un problème de cybersécurité relevant de l’ingénierie : principes de sécurité dès la conception, délais de divulgation des vulnérabilités et nomenclatures logicielles (SBOM) pouvant être produites à la demande au format CycloneDX ou SPDX.

Je comprends l’intérêt de cette approche. Les équipes de sécurité ont l’habitude de prendre en charge les exigences de conformité, et la génération d’une SBOM ressemble à un problème d’outillage que l’on peut résoudre. Il suffit de lancer un outil d’analyse sur le pipeline de développement, d’obtenir un résultat lisible par machine et de l’archiver.

Mais une SBOM est une déclaration concernant votre nomenclature. Elle ne la remplace pas.

La partie la plus difficile commence lorsqu’un problème survient. Une vulnérabilité nouvellement identifiée doit être reliée au composant ou au logiciel concerné, puis aux configurations et aux variantes de produits qui l’utilisent. Les décisions et les modifications des fournisseurs entrent également en jeu. Tout comme les produits déjà commercialisés.

Soudain, générer la SBOM semble être la partie facile.

Le CRA considère la sécurité des produits comme une obligation permanente, et non comme une case à cocher au lancement

Le Cyber Resilience Act (règlement (UE) 2024/2847) est une législation européenne qui couvre les « produits comportant des éléments numériques », notamment le matériel, les logiciels et les produits combinant les deux, mis sur le marché de l’UE. Il est entré en vigueur le 10 décembre 2024.

Dans les grandes lignes, le CRA impose aux fabricants de prendre en compte la cybersécurité dès la phase de conception, de tenir à jour les informations relatives aux composants des produits et aux vulnérabilités, de gérer les vulnérabilités après la mise sur le marché d’un produit et de respecter les obligations de notification lorsque certains problèmes de sécurité surviennent.

Toutes les obligations n’entrent pas en vigueur en même temps. Les exigences en matière de notification s’appliquent à compter du 11 septembre 2026. Les exigences de conformité complètes, y compris le marquage CE, s’appliquent à compter du 11 décembre 2027.

Le non-respect de ces exigences peut entraîner des sanctions importantes.

Le défi opérationnel commence bien avant. Les fabricants doivent savoir ce que contient un produit et maintenir ces informations suffisamment à jour pour pouvoir réagir lorsqu’un problème de sécurité survient.

Vu sous cet angle, le CRA est également un problème de données produit et de traçabilité.

Le compte à rebours commence ce mois-ci, pas en 2027

La date limite de mise en conformité complète avec le CRA, y compris le marquage CE et l’évaluation de la conformité, est fixée au 11 décembre 2027. C’est la date que la plupart des gens retiennent, ce qui donne encore l’impression que le règlement appartient à un avenir relativement lointain.

Mais les obligations de notification commencent le 11 septembre 2026.

Pour certaines vulnérabilités activement exploitées et certains incidents graves, les délais prévoient une alerte précoce dans les 24 heures et une notification plus détaillée dans les 72 heures.

Pensez à tout ce qui doit se passer pendant ces 72 heures. D’où vient le composant concerné ? Quelles configurations l’utilisent ? Un fournisseur l’a-t-il modifié ? Quels produits commercialisés sont concernés ?

Il reste peu de temps pour partir à la recherche de ces réponses.

C’est cette distinction qui, à mon avis, se perd lorsque le CRA est présenté principalement comme un problème de SBOM. Une SBOM indique ce que vos systèmes considèrent comme faisant partie du produit. Une fois qu’une vulnérabilité est identifiée, la définition du produit qui l’entoure devient tout aussi importante.

Pouvez-vous relier le composant ou la dépendance logicielle concernée à la bonne version ? À la bonne configuration ? À la décision du fournisseur qui en est à l’origine ? Et pouvez-vous identifier les produits qui ont réellement été mis sur le marché ?

C’est là que la traçabilité devient opérationnelle plutôt que théorique.

Une SBOM n’est fiable que si la définition du produit qui la sous-tend l’est aussi

Une nomenclature logicielle doit bien être générée à partir de quelque chose.

Les choses se compliquent rapidement lorsque la nomenclature est gérée dans un système tandis que la nomenclature de fabrication a évolué dans un autre. Les informations sur les fournisseurs peuvent se trouver dans un e-mail. Certaines modifications peuvent ne jamais avoir été correctement réintégrées dans l’enregistrement produit gouverné.

La SBOM hérite de ces lacunes. Un format lisible par machine ne garantit pas nécessairement l’exhaustivité des informations.

La fabrication électronique permet de bien illustrer ce problème. Les données PCBA sont encore souvent transmises en aval sous la forme d’un numéro de pièce accompagné d’un ensemble de fichiers de fabrication, tandis que l’intention de conception, les sources approuvées, les substitutions et les décisions de fabrication peuvent être conservées ailleurs.

Puis la réalité intervient.

Un composant devient indisponible. Une alternative est qualifiée. Un fournisseur prend une décision différente pour maintenir la production.

La question qui se pose ensuite est de savoir si quelqu’un peut retracer ce qui s’est passé. La substitution a-t-elle été réintégrée dans l’enregistrement produit ? Les équipes d’ingénierie, de fabrication, de conformité et de sécurité peuvent-elles voir la décision et comprendre où elle s’applique ?

Le logiciel rencontre le même problème sous une autre forme. Les versions du firmware changent. Les dépendances open source évoluent. Les configurations divergent. Les logiciels fournis par des fournisseurs peuvent évoluer indépendamment de la définition mécanique ou électrique.

Au fil du temps, le produit présent sur le marché peut devenir très différent de la définition du produit que l’entreprise pense détenir.

Voici un test utile : identifiez une vulnérabilité dans un composant ou une dépendance logicielle et essayez de retrouver tous les produits, configurations et variantes concernés dans un délai de 72 heures. Puis apportez-en la preuve.

Pour de nombreux fabricants, cet exercice révélera des problèmes qui ont peu à voir avec l’analyse des vulnérabilités.

Une conformité reconstituée au moment de la mise sur le marché ne résiste pas au compte à rebours d’un incident

Dans les secteurs manufacturiers réglementés, une pratique courante consiste à reconstituer le statut de conformité à l’approche d’un jalon de mise sur le marché. Quelqu’un rassemble des informations provenant des systèmes d’ingénierie, des déclarations des fournisseurs, de feuilles de calcul, d’e-mails et du système ERP. Les preuves sont réunies et examinées, puis le produit peut avancer.

C’est fastidieux. Mais cela peut fonctionner lorsque l’entreprise maîtrise le calendrier.

Un incident est différent.

Une vulnérabilité peut être divulguée demain matin. Un fournisseur peut identifier un problème plusieurs mois après l’expédition des produits.

À ce moment-là, le compte à rebours a déjà commencé.

Les relations entre le produit, le composant, le logiciel, la configuration, la modification et les preuves fournies par le fournisseur doivent être disponibles. Les reconstituer sous pression n’est pas vraiment une stratégie.

C’est là que le CRA met en lumière un problème auquel les fabricants sont confrontés depuis des années. La fragmentation des données produit génère des reprises, ralentit les décisions, complique la gestion des modifications et rend la conformité plus difficile.

Elle présente désormais un risque supplémentaire. Le délai peut être imposé de l’extérieur de l’entreprise.

La traçabilité tout au long du cycle de vie permet de réagir rapidement. La SBOM identifie ce qui est censé être présent. La traçabilité permet de comprendre ce qui s’est passé autour de ces éléments : où ils ont été utilisés, ce qui a changé, quelle configuration a été mise sur le marché et quelles preuves du fournisseur ont étayé la décision.

Ces connexions deviennent essentielles lorsque le compte à rebours de notification commence.

C’est ici que la continuité numérique devient concrète

La continuité numérique est évoquée depuis des années en termes d’efficacité de l’ingénierie, de collaboration et de meilleures décisions. Le CRA lui confère une fonction beaucoup plus immédiate.

Il faut pouvoir poser une question difficile concernant un produit et suivre la réponse tout au long de son cycle de vie sans avoir à reconstruire son historique à partir de zéro.

Cela ne signifie pas qu’il faut tout regrouper dans un seul système gigantesque. Pour la plupart des entreprises, ce n’est ni réaliste ni nécessaire.

Cela signifie toutefois qu’il faut maintenir les connexions. Une modification matérielle peut affecter une configuration. Une décision d’un fournisseur peut modifier une source approuvée. Un logiciel peut évoluer séparément tout en restant associé à un produit spécifique mis sur le marché. Les preuves qui sous-tendent ces décisions doivent elles aussi rester connectées.

Le PLM, le MBSE, le MBE, la gestion du cycle de vie des logiciels, l’ERP, les systèmes fournisseurs et les outils de sécurité ont tous un rôle à jouer. La question la plus importante est ce qui se passe entre eux.

Ces relations restent-elles intactes à mesure que le produit évolue ?

Le CRA offre un moyen assez impitoyable de le découvrir.

Le travail que le CRA exige réellement

Rien de tout cela ne constitue un conseil juridique ou en matière de conformité. Les décisions de classification, les procédures d’évaluation de la conformité et les obligations spécifiques de notification doivent être examinées avec des conseillers juridiques et des spécialistes de la conformité qualifiés, et non à partir d’un article de blog publié par un fournisseur.

Pour les organisations d’ingénierie, toutefois, le CRA soulève une question pratique : les données produit peuvent-elles permettre d’apporter rapidement une réponse dans un délai strict ?

La plupart des contenus consacrés au CRA se concentrent sur les exigences du règlement. Mais une autre question mérite d’être posée dès maintenant, avant que l’échéance n’arrive.

À quoi doivent ressembler les données d’ingénierie pour rendre cette réponse possible ?

La différence pourrait déterminer si une notification dans les 72 heures est produite à partir d’informations gouvernées ou si elle se transforme en une course contre la montre impliquant e-mails, feuilles de calcul, appels téléphoniques et souvenirs individuels.

Les outils de sécurité font les gros titres. Mais ce sont la définition gouvernée du produit et la traçabilité qui l’entoure qui rendent ces outils réellement utiles.

Actions recommandées

Aucune de ces actions ne nécessite d’attendre qu’un programme complet de conformité au CRA soit en place. Ce sont des questions auxquelles il vaut mieux répondre avant la prochaine échéance, et non après.

• Inventoriez ce qui entre réellement dans le champ d’application. Identifiez les gammes de produits qui sont considérées comme des « produits comportant des éléments numériques » au sens du CRA et qui nécessiteraient une SBOM correctement tenue à jour. Il s’agit d’un exercice de classification qui relève des équipes de conformité et des conseillers juridiques, et non de l’ingénierie seule.
• Déterminez où se trouve réellement votre nomenclature. Existe-t-il une nomenclature gouvernée unique, reliée aux données de conformité et des fournisseurs, ou plusieurs versions qui divergent entre l’ECAD, l’ERP et des feuilles de calcul que personne n’a rapprochées récemment ?
• Recherchez les substitutions qui n’ont pas été enregistrées. Demandez directement aux fournisseurs et aux fabricants si les substitutions de composants ont suivi le processus de gestion des modifications ou si elles ont simplement été expédiées. Une réponse honnête est plus utile qu’une réponse rassurante.
• Effectuez dès maintenant le test des 72 heures, sans la pression d’un incident réel. Choisissez un produit et mesurez le temps nécessaire pour relier un composant ou une dépendance logicielle spécifique à chaque produit, configuration et variante concernés. Examinez ensuite les preuves qui étayent la réponse. Si la traçabilité dépend de la boîte de réception, d’une feuille de calcul ou de la mémoire de quelqu’un, cela fait partie du problème que le test est censé révéler.
• Traitez les données de conformité et des fournisseurs comme faisant partie intégrante de l’enregistrement produit. Quels que soient les systèmes qui hébergent les données d’ingénierie, ils doivent maintenir les relations entre la définition du produit, les sources approuvées, le statut de conformité, les preuves des fournisseurs, les modifications et les configurations mises sur le marché, afin que la documentation devienne un résultat naturel du travail quotidien plutôt qu’un projet qu’il faut reconstruire avant chaque mise sur le marché ou réponse à un incident.

Pour approfondir la manière dont la volatilité de l’approvisionnement, les modifications multidomaines et les exigences croissantes en matière de preuves convergent pour les fabricants de produits high-tech et électroniques, notamment avec le passeport numérique des produits (DPP) et le CRA, consultez l’article complémentaire Des données fragmentées à la résilience dans le secteur high-tech.