Bonjour tout le monde. On continue la partie juridique.
Quand je parlais avec des juristes il y a cinq ans, on parlait de licences. C’est sûr. Quand je parle avec des juristes maintenant, on parle de quelque chose d’autre.

Qu’est-ce que le Cyber Resilience Act [1] ? Vous voyez le petit marquage Journal officiel de l’Union européenne ? Oui, c’est la loi en vigueur. Qui a entendu parler de ce sujet ? Oui, au moins en partie. Qui le connaît bien ? OK. Ça fait juste quelques dizaines de pages !

Je ne suis pas juriste et je ne veux pas le devenir. Je parle de ma compréhension d’aujourd’hui. Si vous avez besoin de conseils juridiques sur ce sujet, il faut chercher des avocats, surtout dans un an ou un peu plus, quand la façon dont ça fonctionne sera bien comprise.

Par contre, je suis une spécialiste de cybersécurité. Je travaille surtout dans l’embarqué. Je contribue au noyau Linux. J’ai contribué et je contribue toujours au projet Yocto [2] et à beaucoup d’autres choses, et je m’occupe beaucoup de process de sécurité. Ces trois dernières années, je me suis beaucoup occupée de la standardisation autour du CRA. Et alors !

Pourquoi ?

D’abord, pourquoi en est-on arrivé là ? On est arrivé là à cause de la sécurité des produits embarqués, la sécurité catastrophique des produits embarqués. Un des exemples dans la presse : l’espionnage par les aspirateurs et ce n’est pas le seul exemple, il y en a d’autres. Qu’est-ce qu’il se passe quand le législateur apprend l’existence d’un problème ? Il le résout par la législation. C’est donc ce qu’on a eu.

Où sommes-nous ?

Où sommes-nous dans l’affaire ?
Comme on a vu, nous sommes dans le Journal officiel.
Soumettre un patch dans cette législation, c’est un processus de quelques années, soumettre une merge request, c’est un peu long !

Chronologie ?

Les dates sont les suivantes.
L’entrée complète en vigueur aura lieu en décembre 2027, mais il y a une échéance en septembre de cette année [2026]. Ce sont les notifications des vulnérabilités exploitées dans tous les produits et c’est dans quelques mois.
Les normes qui sont en lien avec la législation sont censées être prêtes cette année. Ça avance, mais il y a encore beaucoup de boulot.

Qui est concerné ?

Qui est concerné ?
Il y a une définition : « Produit comportant des éléments numériques ».
Définition plus complète : « C’est tout logiciel ou produit matériel qui est connecté ou connectable. » Toute la domotique est dedans, c’est sûr, et le logiciel installé sur un poste d’utilisateur aussi.
N’importe où ces logiciels ou ces matériels ont été conçus et fabriqués, s’ils sont vendus ou distribués dans l’Union européenne, c’est inclus.

Produits

Il y a une partie importante qui dit que les traitements à distance, donc si une application envoie des données, si un produit envoie des données pour des traitements sur un serveur, l’application qui tourne sur ce serveur est une partie de ce produit, donc c’est dedans.

Qu’est-ce qui n’est pas dedans ? Les sites web, les produits qui ont leur propre réglementation, par exemple les automobiles, mais pas les trains qui sont dedans.
Les projets de loisir, de hobby ne sont pas dedans.
Tous les autres sont dedans.

Classification des produits

Il y a une classification des produits dans la réglementation.
Pour la majorité des cas, c’est de l’auto-évaluation. Dans 90 % des cas, c’est de l’auto-évaluation.
Après, il y a les produits importants de classe 1, de classe 2 et les produits critiques.
Très vite, quelques exemples de produits importants :

• les navigateurs web
• les boot managers
• les interfaces réseau
• les systèmes d’exploitation : si vous faites votre propre distribution Linux, c’est un produit important
• Les routeurs
• les produits de la maison connectée.

Dans la classe 2, il n’y en a pas beaucoup : hyperviseurs, pare-feux.

Les critiques, ce sont plutôt les matériels : carte à puce, produits de sécurité.

Important ? Critique ?

Il y a des définitions.
Il y a déjà une réglementation d’exécution qui donne la définition. C’est assez intéressant parce qu’on peut voir ce qu’est le système d’exploitation. Si vous ne savez pas, vous pouvez voir ce qu’est le système d’exploitation dans la loi.

Les acteurs

Dans l’écosystème de toutes les parties prenantes dans le logiciel et le matériel, il y a plusieurs acteurs :

• les fabricants qui sont ceux qui monétisent les produits
• les intendants de logiciels ouverts
• les contributeurs à l’open source

Déjà, première bonne nouvelle : les simples contributeurs de projets open source : zéro obligation. Ce n’était pas gagné au début.
Qui a des obligations ? Ce sont les fabricants, donc ceux qui monétisent. Là, il y a une conformité complète et il faut mettre le marquage CE sur les produits et sur les logiciels aussi. Je ne sais pas comment on va faire.
Pour les intendants de logiciels ouverts, il semble qu’il y ait moins d’exigences et pas de marquage CE.

Fabricant ou intendant de logiciels ouverts ?

Quelle est la différence entre les deux ?
Les fabricants monétisent et ils ont l’obligation de faire l’analyse, due diligence, de toutes les dépendances, et cela inclut toutes les bibliothèques et outils qu’ils ont mis dans leurs produits.
De l’autre côté, l’intendant des logiciels ouverts, c’est une personne morale, c’est important, une personne seule ne peut pas être dans cette catégorie, qui supporte un produit, un projet open source et ne le monétise pas. Là, il y a juste à avoir la politique de sécurité et pouvoir être en contact avec des organismes de surveillance si besoin. Ce n’est pas très compliqué.

Quelles sont les obligations visibles par les utilisateurs du produit ?

Côté obligations.
J’aimerais bien parler de choses qui vont être visibles à tout moment. Il y a quelque chose ici.

Mises à jour logicielles

Dans le CRA, il y a la période d’assistance. Qu’est-ce que c’est ? C’est une période pendant laquelle le fabricant doit fournir des mises à jour de sécurité sans frais. La période d’assistance est, par défaut, de cinq ans, il faut justifier pour faire moins, et elle doit être en lien avec la durée de vie des produits. Les fabricants vont devoir nous dire quelle est durée de vie prévue de leurs produits. Ils n’ont pas droit de vendre les produits après la fin de la période d’assistance.

Gestion des vulnérabilités

La gestion des vulnérabilités.
Si les fabricants ont découvert une faille dans les projets open source qu’ils utilisent, ils ont l’obligation de notifier ces projets-là. On peut donc s’attendre à ce que les projets reçoivent des notifications et des patchs pas nécessairement magnifiques, mais ils vont recevoir des choses.
Le projet upstream n’a aucune obligation de faire quelque chose. Par contre, le fabricant doit fournir une mise à jour, donc il se débrouille pour faire les correctifs.
Pour la publication des correctifs, il est écrit « sans délai », on va demander aux avocats ce que ça veut dire.
Et il faut communiquer sur les failles qui ont été corrigées.
Pour les produits, dans lesquels il y a un traitement de données, la fonction de mise à jour automatique doit avoir une option de désactivation par l’utilisateur.

Analyse des risques

La base de toute la législation, c’est l’analyse des risques : pour chaque produit mis sur le marché, il faut faire une analyse des risques. Et seulement l’analyse des risques définit les mesures de sécurité. J’ai déjà entendu certains fournisseurs qui disent qu’il faut absolument avoir une fonctionnalité x dans les produits pour cela. Non, c’est l’analyse des risques qui dit ce qu’on doit faire.
L’analyse des risques, c’est notre responsabilité et, d’un point de vue juridique, ce serait la seule défense des fabricants. C’est en même temps technique et juridique. Ça va être super !

L’analyse des risques d’un produit final doit inclure l’analyse de tous les composants utilisés. On sait qu’entre 70 et 90 % des composants utilisés sont open source. Il faut au moins la liste de ce qu’ils ont mis. Intéressant.

Comment influencer et connaître l’avancement ?

Comment peut-on influencer ce qui se passe et connaître l’avancement ?
Aujourd’hui, c’est déjà un peu tard pour influencer ! Il fallait le faire il y a un an ou deux.
Aujourd’hui, il y a la rédaction de standards autour, mais on peut savoir ce qui se passe, les nouvelles explications qui sortent, les standards qui sortent.

Pour en savoir plus

Pour en savoir plus, il y a, bien sûr, la base [1], il y a aussi un tutoriel [3], c’est le seul que je connaisse publié en français, tous les autres sont en anglais.

Comment s’impliquer ?

Si vous êtes dans un organisme un peu plus grand, il est encore possible d’influencer les normes qui sont en cours d’élaboration. Il faut être soit dans le CEN CENELEC [Comité européen de normalisation en électronique et en électrotechnique] soit dans l’ETSI [European Telecommunications Standards Institute].
Du point de vue de l’open source, le travail sur la réponse, sur le conseil, comment gérer les cas plus compliqués, il y a deux groupes : Open Regulatory Compliance et Open SSF.
Si vous êtes intéressé par ce sujet, il y a des ressources, il y a des cours en ligne, il y a l’information, à voir.

Je communique beaucoup sous ce sujet ces derniers temps. Je suis facile à trouver en ligne.
On va avoir du temps pour deux questions peut-être.

[Applaudissements]

C’est le moment de poser vos questions

Public : Merci beaucoup, c’était passionnant.
Si j’ai bien compris – je voudrais que tu me corriges – comme Microsoft, par exemple, ou Apple mettent produits libres dans leurs produits, sont obligés de fournir les patchs pour tout ce qu’ils incluent, on pourrait tous les poursuivre en justice et obtenir réparation parce qu’ils ne vont pas être capables de tout faire. En tout cas, les attaquer, ça voudrait déjà pas mal la peine.

Marta Rybczynska : Ce n’est pas l’utilisateur final qui peut attaquer. Ce sont les organismes de surveillance des marchés qui peuvent, mais on peut envoyer une petite lettre. L’obligation de tout fournisseur qui entre dans cela, c’est de fournir les correctifs pour toutes les corrections de sécurité qu’il fait en interne.

Public : Pas mal. Et ils n’ont pas encore réagi pour dire « nous ne sommes pas capables de faire ça, on ne le fera pas. » ?

Marta Rybczynska : Je ne peux pas vous dire ce qui se passe maintenant dans les organismes de normalisation sur le sujet. C’est intéressant.

Public : Bonjour. Quand on dit « vendu en Europe », c’est « vendu à une entreprise ou à un particulier européen » ou « vendu par une société européenne » ?

Marta Rybczynska : C’est vendu à un particulier ou à une société en Europe. Dans la loi, c’est beaucoup plus compliqué, il n’y a pas que les fabricants, il y a aussi les importateurs, les distributeurs et les autres qui ont aussi des obligations, mais j’ai voulu simplifier. À priori, ils ont tout couvert.

Public : OK. Donc une entreprise étasunienne, par exemple, qui vendrait directement à une société française, serait concernée.

Marta Rybczynska : Tout à fait.

Public : Merci.

Public : Bonjour. Merci. Ma question est plus orientée développeurs. Je sais qu’avec ce genre d’acts qui vont passer, qui vont être intégrés dans notre quotidien, un peu comme le RGPD [Règlement général sur la protection des données à caractère personnel], beaucoup de choses vont changer, notamment le fait qu’il va falloir qu’on liste, maintenant, tout ce qui est contenu dans nos applications. Tous les micro-services qu’on va déployer, tous les logiciels embarqués qu’on va livrer à nos clients devront être certifiés quelque part. Je sais qu’aujourd’hui il y a des outils, notamment autour de la conteneurisation, qui permettent de faire ça, avec le SBOM [Software Bill of Materials] notamment : le conteneur livré chez le client est analysé absolument de bout en bout, avec toutes les librairies, les outils qui sont intégrés dans ce conteneur. Mais qu’est-ce qui se passe pour des applications qui sont chez des clients aujourd’hui qui, potentiellement, sont vulnérables ? Est-ce que la loi est rétroactive sur ces applications-là pour les fournisseurs de l’époque ?

Marta Rybczynska : Pour les exigences de sécurité, ce n’est pas rétroactif. Par contre, s’il y a une mise à jour fonctionnelle importante, ça rentre dans cette loi.
Un autre sujet qui n’est pas rétroactif, mais qui s’applique à tout, c’est la notification concernant les vulnérabilités qui sont en cours d’exploitation et les failles de sécurité dans l’infrastructure des fabricants. Pour cela, peu importe si c’est sous l’ancienne version ou non, les obligations sont là, à partir de septembre de cette année.

Public : J’ai une deuxième question du coup : est-ce que vous pensez que les entreprises vont aller un peu plus vers de la conteneurisation d’applications à cause de cet act ?

Marta Rybczynska : Je ne sais pas. Aujourd’hui, je vois qu’avec les conteneurs, tous les préparatifs comme la génération des SBOM sont devenus beaucoup plus compliqués, parce qu’il y a beaucoup plus de composants et aujourd’hui, la combinaison de plusieurs SBOM, par exemple si on a l’appli multiconducteur, ce n’est pas trivial à faire. On verra.

Public : Merci.

Organisateur : Merci à tous. On peut l’applaudir.

[Applaudissements]