Les défis et opportunités du CRA pour les communautés Open Source

Publié au Journal Officiel de l’UE le 20 novembre 2024, le Cyber Resilience Act (CRA) apparaît dans un contexte généralisé de croissance des risques de cybersécurité et de cybermenaces dans un monde toujours plus connecté. Il s’associe à la publication d’autres directives visant à réguler le marché intérieur de l’Union européenne telles que l’AI Act (Artificial Intelligence Act) ou encore le DSA (Digital Services Act).

Le CRA, dont les mesures les plus contraignantes s’appliqueront courant 2026 et 2027, a un impact significatif sur l’ensemble des communautés de logiciels, qu’ils soient libres ou propriétaires. Ainsi dans un contexte plus spécifique, les communautés Open Source se doivent d’adapter leurs pratiques. Au-delà de ces communautés, l’Open Source, qui représente 10 % du secteur de l’informatique au niveau européen, est aujourd’hui omniprésente dans les produits numériques induisant alors un impact sur tout produit numérique utilisant du code ouvert.

Ambivalent, le CRA apparaît comme un défi ou comme une opportunité pour la filière Open Source selon le prisme qui lui est donné.

Ce règlement européen structurant sera complété par un certain nombre de documents établis par la Commission (actes d’exécution, doctrines, etc.) ou pour son compte. Pour toute entreprise de la filière du numérique, la compréhension de ses tenants et aboutissants de cet ensemble, pour se positionner (rôle par rapport au CRA, obligations et sanctions applicables) sera un processus complexe.

Contextualisation et problématiques principales

La publication du CRA est le jalon fondateur, suivi d’une période de 2-3 ans durant laquelle les communautés concernées vont pouvoir s’organiser et travailler ensemble pour mettre en place des outils permettant de comprendre le texte et se conformer aux obligations qui leur sont imposées.

Au-delà, la publication du CRA démontre les difficultés du législateur pour comprendre et encadrer les pratiques de l’écosystème. L’absence de prise en compte de l’Open Source dans la première version du CRA fait ainsi écho à un manque de communication avec d’une part les acteurs de l’Open Source (moins bien organisés en termes de lobbying que les éditeurs traditionnels) et d’autre part l’OSPO (Open Source Program Office) de la Commission européenne (certainement en raison du silo normatif européen, très cadré et donc moins enclins à s’adapter à des changements d’équilibre ainsi que c’est nécessairement le cas en matière d’Open Source). C’est lors du processus de rédaction que les efforts des associations et fondations (Eclipse, OFE ou encore le CNLL) ont permis une meilleure prise en compte des problématiques de terrains. La nouvelle version du texte s’est ainsi enrichie par la création d’un rôle d’intendant de logiciels ouverts (en anglais Open Source steward) et une exception spécifique en matière d’Open Source (qui a déjà été réintroduite dans d’autres textes tels que la Directive sur la responsabilité du fait des produits défectueux (nouvelle PLD)) .

Dans tous les cas, le CRA impacte déjà le modèle économique de l’ensemble des acteurs de la filière du numérique, d’où l’importance de s’y préparer rapidement. En conséquence, il a été estimé dans l’étude d’impact de la Commission Européenne publiée en 2021 que l’application du CRA induit une augmentation du coût de développement d’environ 30 %.

En matière d’Open Source, la mise en œuvre du CRA s’accompagne de plusieurs questionnements  :

• Responsabilité des acteurs : la chaîne de développement d’un produit numérique fait appel à des acteurs hétérogènes (développeur, contributeur, intégrateur, etc.). Il s’agit de comprendre quelles responsabilités sont associées à quels acteurs ;
• Impact sur les pratiques existantes : le CRA rend dans certains cas, caduques les clauses de non-responsabilité des licences Open Source. Comment prendre en compte ce facteur ? Il rend par ailleurs essentielle la fourniture d’un Software Bill of Materials (SBOM). Comment aider chaque acteur à les fournir ? ;
• Professionnalisation des développeurs Open Source : d’un côté le CRA peut être analysé comme un facteur supplémentaire de pression sur des développeurs de logiciels libres souvent bénévoles ou précaires, risquant ainsi de démobiliser la communauté. De l’autre, le Règlement pourrait forcer la main d’acteurs plus importants à soutenir davantage des projets Open Source « critiques » que ce soit par l’allocation de ressources, le développement d’outils et de processus.

Comprendre le guide via un outil didactique

Le CRA est un texte très large qui n’est pas réservé aux logiciels libres, ni seulement aux logiciels puisqu’il s’applique à 1) tous les produits comportant des éléments numériques (logiciels et matériels), 2) mis à disposition sur le marché 3) dont l’utilisation comprend une connexion à un réseau. Sa difficulté tient notamment dans le fait qu’il introduit des nouveaux concepts qui ne sont pas forcément familiers et applicables aisément à l’écosystème du libre.

Afin d’accompagner les acteurs dans leur prise en main du CRA, inno³ et le CNLL ont produit fin 2024 un « Guide de conformité au Cyber Resilience Act à destination des acteurs de la filière Open Source ». Ce guide s’est inscrit dans une démarche d’anticipation des risques et opportunités du CRA.

Malgré des réécritures du texte, certaines contraintes amènent toujours des questionnements. Notamment, une problématique centrale est celle de la typologie d’acteurs présentée dans le CRA. Il peut être difficile de savoir quel rôle endosser : fabricants, importateurs ou encore Open Source Steward à l’échelle du CRA. Le rôle du mandataire par exemple est très peu connu pour les communautés du logiciel libre.

Pour expliciter ces notions, le guide présente des schématisations permettant à chacun et chacune de se positionner vis-à-vis des rôles présentés dans le CRA.

Une fois les rôles clarifiés, les obligations et sanctions peuvent être déterminées. Le guide détaille (sous forme de visualisation) les obligations, responsabilités et sanctions en fonction des 3 grandes étapes de la vie d’un produit : avant la mise sur le marché, pendant la mise sur le marché et après la mise sur le marché. Encore une fois, la distinction entre ses phases est propre au fonctionnement du marché européen, d’où le besoin de les expliciter dans le guide.

En fonction de leur rôle, les acteurs soumis au CRA auront des obligations différentes : une obligation de moyens avant tout pour l’Open Source Steward, une obligation de résultats, notamment pour le fabricant. Ainsi si on ne peut cumuler plusieurs rôles pour le même produit, il est possible d’avoir un rôle différent selon chaque produit mis sur le marché.

De manière générale, le CRA introduit un principe de régime de responsabilité partagé entre l’ensemble des acteurs comme en témoignent les obligations de « due diligence » ou encore le système d’attestation volontaire. Dans ce contexte, l’Open Source Steward créé par le CRA aura le rôle de mettre en place l’environnement favorable pour limiter les problématiques de cybersécurité et devra apporter des garanties pour l’ensemble des potentiels clients.

Contrairement aux États-Unis, où la stratégie nationale de cybersécurité de l’administration Biden met l’accent sur la responsabilité des entités commerciales qui intègrent et distribuent des logiciels Open Source, l’approche européenne adoptée par le CRA repose sur une répartition plus diffuse des responsabilités. Cette logique de responsabilité partagée, bien que souple, complexifie la lisibilité des obligations pour chaque acteur.

La détermination des rôles et des obligations dépend d’une cartographie précise des acteurs impliqués dans le cycle de vie du produit. Par exemple, dans le cadre du projet Eclipse, la Fondation Eclipse fournit le code en tant qu’Open Source Steward. L’éditeur d’une version commercialisée porte les responsabilités en tant que fabricant et l’intégrateur sera distributeur.

Quelles solutions pour appliquer le CRA à ses produits ?

Afin de répondre aux injonctions portées par le CRA, il sera nécessaire de favoriser l’utilisation de SBOM (software bills of materials) permettant l’inventaire des composants d’une solution. En effet, dans un contexte de besoin de sécurité de plus en plus important face aux menaces actuelles, le SBOM comme solution juridique et technique est essentiel pour la mise en conformité des acteurs économiques. Pour plus d’informations, lisez notre billet dédié à la présentation de ce sujet.

Concernant les solutions techniques, l’exemple de PURL a été rappelé pendant les échanges, car il permet de retrouver facilement des ressources via l’usage d’identifiants pérennes.

La standardisation d’outils de mise en conformité est en effet importante pour la conception de logiciels critiques ou non critiques. Ce travail a déjà démarré au sein de fondations telles que la Fondation Mozilla ou la Fondation Eclipse qui mutualisent les outils et standards facilitant la mise en conformité. Ainsi, si le respect des obligations du CRA permet l’obtention d’un marquage CE sur les produits numériques, ce système pourrait être complété par l’usage de labels de conformité CRA mis en place par la communauté.

Les pistes futures pour répondre au CRA

Afin de répondre au mieux aux injonctions portées par le CRA, il est nécessaire de travailler collaborativement sur des guides, des lignes directrices et des bonnes pratiques communes. Ce mode de travail se doit d’être collectif, communautaire et mutualisé.

Certains projets portés par la communauté Open Source répondent à ce mode de travail :

• la création d’outils d’analyse de code/détection des vulnérabilités adaptés au CRA, le travail de vulgarisation du Règlement porté par la fondation Eclipse au travers d’un Groupe de travail. L’objectif du GT est d’aligner les pratiques et usages au niveau de l’Union européenne en travaillant avec d’autres fondations :
  • mise en place d’une FAQ pour que chaque acteur puisse se positionner,
  • rôle d’interlocuteur unique pour échanger avec l’UE sur la production de guide et aussi avoir des retours sur l’écriture et modification sur le texte du CRA,
  • favoriser la réponse aux appels d’offre de l’UE pour s’outiller pour que les entrepreneurs et les SME puissent être accompagnés.

L’objectif commun serait de produire des guidelines pour 2027. De plus, le CRA est déjà et sera encore complété par de nombreuses doctrines.

Le groupe de travail animé par le CNLL et inno³ continuera à se réunir durant les prochains mois afin de développer les aspects non encore traités par le guide (tels que la mise en œuvre du CRA au sein de projets communautaires ou dans le cadre des marchés publics) et d’illustrer ces éléments par le développement de cas d’usage concrets mettant en relations plusieurs acteurs et prestataires au sein d’un produit complexe (étendre le sujet au-delà des qualifications du CRA pour envisager les partages de responsabilité susceptibles d’être contractualisés). Ce groupe étant ouvert, il pourra donné lieu à la production d’autres ressources jugées utiles par les participants.

Et au-delà du CRA ?

Plus généralement, la cybersécurité est un enjeu systématique, d’ampleur de plus en plus importante, qui amène à se poser des questions relatives à la résilience, et à la manière de résister par rapport aux risques globaux actuels (ex. pénurie de ressources matérielles, chaos informationnel, évolution des droits de douane, guerre commerciale, etc.). En France, plus d’une centaine d’organismes, coordonnés par l’ANSSI (Agence nationale de la sécurité des systèmes d’information), traitent des questions de cybersécurité sur différentes thématiques telles que les drones ou encore les radars.

Dans ce contexte, il devient nécessaire pour les entreprises et tout sous-traitant de mettre en place un ensemble de pratiques pour respecter l’ensemble des normes européennes (NIS2, RGPD, DORA, CRA etc.) et de répondre aux besoins des clients. Pour chaque acteur, il est important d’anticiper les crises afin de les gérer au mieux et de mettre en place une stratégie adaptée pour mettre en place des règles, une temporalité et réduire ainsi au minimum les risques.