Le Cyber Resilience Act : De la contrainte réglementaire à l'opportunité stratégique pour l'Open Source?

Transcript

1. 11 novembre 2025 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique Redhat Summit – Session CNLL 6 novembre 2025
2. Introduction
3. 3 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Qui sommes-nous ? □ Benjamin Jean ▪ fondateur et président du cabinet inno³, ▪ vice-président de la commission Open Source de Numeum □ Stéfane Fermigier ▪ fondateur et président Abilian SAS, ▪ co-président CNLL et APELL ▪ co-fondateur EuroStack
4. 4 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Guide de conformité au CRA □ En 2024, le CNLL (Conseil National du Logiciel Libre) et inno³ ont travaillé ensemble sur la rédaction d’un guide avec pour objet d’accompagner les acteurs de l’Open Source dans la compréhension du Cyber Resilient Act. ▪ Ce guide est disponible sous licence libre favorisant ainsi son amélioration et sa dissémination. □ Nous travaillons actuellement sur une seconde version du guide, ▪ enrichie d’une intégration des contributions et travaux de la commission européenne (Guidelines) ▪ Illustré par plusieurs études de cas concrets. Guide disponible ici : https://code.inno3.eu/ouvert/guide-cra
5. 5 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Sommaire □ Contexte (5’) □ Enjeux de la conformité logicielle (5’) □ Nouvelles obligations du CRA (5’) □ Opportunités économiques (5’) □ Synthèse (5’) □ Questions (5’)
6. Contexte
7. 7 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Contexte □ Contexte : ▪ Approche réglementaire du marché intérieur de l'Union européenne ▪ Enjeux cybersecurité croissants : NIS (2016), Cybersecurity Act (2019), NIS 2 (2022), etc. □ Objectif : ▪ renforcer la sécurité des produits numériques au bénéfice des consommateurs et des entreprises dans toute l'Union européenne. □ Comment : ▪ en introduisant de nouvelles exigences de cybersécurité pour tout produit matériel et logiciel tout au long de son cycle de vie. □ Quand : ▪ proposition du CRA puis nouvelle version adaptée en réponse aux retours des acteurs de l'open source : le CRA est le premier Règlement réglementant directement l’Open Source. ▪ publié le 20 novembre 2024 : les acteurs économiques ont 36 mois pour s'adapter aux nouvelles exigences après l'entrée en vigueur qui débute le vingtième jour suivant la publication (jusqu'au 11 décembre 2027). https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
8. Enjeu de la conformité logicielle
9. 9 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Granularités de l’Open Source, quelles réalités techniques ? Applications complètes Briques d’infrastructure Bibliothèques / frameworks
10. 10 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Perspective : un rôle d’éditeur qui invisibilise l’Open Source (ou les utilisateurs) Open Source Éditeurs Clients / Utilisateurs
11. 11 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Perspectives : le client ne voit que l'application, pas la complexité sous-jacente du code Open Source Code éditeur Code Open Source Vue du client Application éditeur
12. 12 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Perspectives : une vision souvent partielle de l’ensemble des composants Open Source effectivement mobilisés Dépendances directes (premier niveau) Dépendances indirectes (transitives) Vue de l’éditeur (hors développeurs)
13. 13 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno « « Supply chain » « attacks » » □ Une « supply chain » complexe, où des éléments même massivement utilisés reçoivent peu de soutien. □ Des incidents majeurs se produisent périodiquement : Heart bleed, Log4Shell, XZ □ Des réponses surtout orientés sécurité, soutenues par les GAFAM (AMAMA) via la Linux Foundation / OpenSSF □ Le problème va en s’aggravant, cf. le ver NPM Shai Hulud, qui a notamment affecté des paquets publiés par CrowdStrike « When the Log4j bug was discovered last November, it was already too late. We'd hit snooze on Heartbleed's wakeup call and holy shit had we ever overslept » Cory Doctorow, auteur et journaliste
14. 14 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Pas une « Supply chain » et pas toujours des « attacks » □ Contrairement à une supply chain classique, il n’y a pas de relation contractuelle entre mainteneurs et utilisateurs □ Les problèmes de sécurité sont souvent des conséquences des problèmes de maintenance, lié à la divergence entre création de valeur / captation de valeur. □ La conscience de cet écart mène des projets à se saborder (cf. Color.js) □ Le problème n’est pas la détection mais la remédiation : cf. LibXML2 => Officiellement détecté comme un composant critique ayant besoin de soutien en 2020 => Aucune action => Démission du mainteneur en 2025 □ Des initiatives publiques (Sovereign Tech Agency en Allemagne) et privées (Copie privée, Open Source Pledge) □ Le CRA n’est pas qu’une question de sécurité mais aussi d’évolution des rapports économiques entre acteurs. « I am not your supplier » Thomas Depierre, mainteneur
15. 15 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno La conformité juridique □ Mentions légales obligatoires : ▪ 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. (Licence BSD 3 clause) □ Clauses contractuelles obligatoires : ▪ 3.1.b.i) effectively disclaims on behalf of all other Contributors all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose; ▪ ii) effectively excludes on behalf of all other Contributors all liability for damages, including direct, indirect, special, incidental and consequential damages, such as lost profits; (Licence Eclipse 2.0)
16. 16 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Enjeux des SBOMs Conformité Soutenabilité Sécurité SBOM □ Le SBOM (Software Bill of Materials) répond à un triple enjeu : ▪ Sécurité : détection d'impact immédiate lors d'une nouvelle faille (type Log4Shell). ▪ Conformité CRA : documentation requise et élément de preuve de la maîtrise de votre supply chain. ▪ Soutenabilité : identification des dépendances critiques àsoutenir. □ Intégré dans une démarche de conformité en continu (CI/CD), le SBOM est central pour automatiser la sécurité et la conformité dans une approche DevSecOps : ▪ Génération auto du SBOM à chaque build (SPDX, CycloneDX). ▪ Analyse continue des vulnérabilités et des licences. ▪ Alertes et blocage automatique du déploiement si un risque est détecté.d ▪ Documentation de conformité générée en même temps que le produit. SPDX : Standard pour échange d’informations de PI (ISO/IEC 5962:2021) CycloneDX: The International Standard for Bill of Materials (ECMA-424)
17. 17 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Un effort de standardisation de la conformité Open Source □ Projets communautaire, dans le cadrede la Linux Foundation □ Norme ISO/IEC 5230:2020 □ 6 sujets : ▪ Fondamentaux : existence et visibilité d’une politique Open Source ▪ Définition des rôles et support des tâches (dont un correspondant Open Source) ▪ Processus de création de BOM et validation ▪ Processus de création des artefacts de conformité ▪ Politique de contribution ▪ Autocertification
18. Nouvelles obligations du CRA
19. 19 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Des obligations pour quoi ?
20. 20 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Des obligations pour qui ?
21. 21 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Obligations du CRA :
22. 22 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Focus sur certaines obligations : □ Fabricant : ▪ Appliquer, ou de faire appliquer, les procédures de conformité établies par le CRA pour les produits qu’il commercialise (déclaration de conformité, apposition du marquage CE, etc.). ▪ Établir et maintenir une documentation précise, incluant une SBOM. ▪ Signaler aux autorités et prendre toutes les mesures nécessaires pour corriger la vulnérabilité et diffuser les correctifs correspondants (avec une période d’assistance de minimum 5 années après la mise sur le marché). □ Intendant de logiciels ouverts (open source steward) : ▪ Mettre en place et documenter une politique de cybersécurité qui vise à garantir la sécurité des produits numériques et à traiter efficacement les vulnérabilités signalées par les développeurs. Elle inclut des mesures pour documenter, corriger et partager les vulnérabilités au sein de la communauté des logiciels ouverts. ▪ Fournir la documentation relative à leur politique de cybersécurité en cas de demandes. ▪ Se conformer aux exigences de signalement en cas d’incidents graves affectant la sécurité des produits ou les systèmes d’information qu’il fournit pour leur développement. □ Distributeur : ▪ Vérifier que le produit mis sur le marché porte le marquage CE et que le fabricant ainsi que l’importateur ont rempli leurs obligations, en fournissant les documents nécessaires. ▪ S’assurer que des mesures correctives sont prises, telles que le retrait ou le rappel du produit en cas de vulnérabilité,et prévenir le fabricant. ▪ Être en mesure de fournir les documents prouvant la conformité du produit et coopérer pour résoudre les risques de cybersécurité.
23. 23 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Transformation de l’organisation □ En interne : 1) Étendre la politique de conformité de l’organisation aux enjeux du CRA 2) Articuler la politique Open Source avec la politique cyber : les enjeux sont convergents, mais différents (et non suffisants) ; 3) Assurer une connaissance complète des composants numériques intégrés à ses produits (développements propres et sous-traitance) ainsi qu’aux services connectés □ En externe : ▪ Intégrer ces obligations dans les relations avec les tiers ▪ Comment : • Globalement : Obligations + preuves d’execution + vérifications lors des recettes ; • Concernant l’OS : En formalisant des clauses spécifique pour l’obtention des SBOM et en imposant le reversement upstream des correctifs sur les produits vulnérables □ De manière générale : ▪ Il faut dépasser les seules obligations du CRA car la réglementation tend vers une responsabilité accrue (ex : ne pas demander uniquement le premier niveau de dépendance) ▪ Il faut transformer les relations avec les upstream : passer d’une conscience de l'utilisation à un rôle proactif de contributions.
24. Opportunités économiques
25. 25 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Une exception pour favoriser l’innovation ? □ Objectif : ▪ L’UE ne souhaite pas freiner l’innovation et considère l’Open Source comme un accélérateur pour la transformation numérique des acteurs européens □ Cette exception est également présente dans les autres réglementations européennes ▪ NPLD ▪ AI Act □ Cette exception intervient néanmoins après l’intervention de nombreux acteurs du secteur qui avait mis en lumière les défis d’application de la première version du CRA dans le contexte décentralisé de l’Open Source.
26. 26 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Exception de l’Open Source □ Le principe développé par le CRA est que seuls les produits distribués dans un cadre commercial sont soumis aux exigences de cybersécurité □ En droit européen, la qualification d’une activité comme commerciale repose sur la notion d’activité économique, définie par la Cour de justice de l’Union européenne (CJUE) comme « toute activité consistant à offrir des biens ou des services sur un marché donné ». □ Ainsi, peuvent être considérées comme non commerciales, notamment s’il est possible de démontrer que : ▪ la distribution est gratuite et sans objectif lucratif ▪ le financement est assuré par des dons ou des subvention ▪ l’absence de services payants associés □ L’appréciation du statut s’appréciant par produit mis sur le marché, il est possible de publier parallèlement : ▪ certains projets Open Source non commercialisés (exclu du champ d’application du CRA) ; ▪ Des versions commercialisées de ces mêmes logiciels. □ L’organisation sera ainsi fabricant au titre des versions commercialisées mises sur le marché et potentiellement uniquement Open Source Steward pour les versions Open Source
27. 27 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Une opportunité pour les acteurs du numérique □ Le règlement renforce les obligations des fabricants (et de toute la supply chain) tout en excluant expressement de son périmètre les logiciels Open Source ; □ Ce régime en deux temps ▪ imposera de clarifier avec précision ce qui est de l’ordre des produits, des services, et de leur articulation (voire des dépendances entre les produits et les services) ; ▪ Offrira un cadre commun d’innovation et de valorisation par l’Open Source □ Le CRA force les fabricants à prendre conscience des composants dont dépendent leurs produits numériques. □ Cela leur permettra ▪ de pleinement bénéficier des dynamiques communautaires sous jacentes : ▪ De mutualiser aussi les coûts de cyber associé, avec une mutualisation des investissements d’autant plus importantes que les composants sont massivement utilisés ;
28. 28 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Stratégie de valorisation Open Source subi Usage opportuniste Informatique « grise » Open Source maîtrisé Risques encadrés Validation des usages Open Source décidé Engagement stratégique Enjeux métiers & RH
29. Synthèse et conclusion
30. Questions
31. 31 CRA & Open Source : de l'obligation de conformité à l'opportunité stratégique - CNLL/ inno Crédits • Photo de David Vives sur Unsplash • Photo de Joe Dudeck sur Unsplash • Photo de Jake Nackos sur Unsplash