1 pièce(s) jointe(s)
Loi européenne sur la cyber-résilience : qu'est-ce que cela signifie pour l'écosystème open source ?
Les appareils intelligents connectés à Internet devront se conformer à des règles strictes de l'Union européenne en matière de cybersécurité, sous peine de se voir infliger une amende ou d'être bannis
Les appareils intelligents connectés à Internet, tels que les réfrigérateurs et les téléviseurs, devront se conformer à des règles strictes de l'Union européenne en matière de cybersécurité, sous peine de se voir infliger une amende ou d'être bannis de l'Union, selon un document de la Commission européenne
Les préoccupations relatives aux attaques de cybersécurité se sont accrues ces dernières années à la suite d'incidents très médiatisés où des pirates informatiques ont endommagé des entreprises et exigé d'énormes rançons.
L'exécutif européen annoncera sa proposition, connue sous le nom de "loi sur la cyber-résilience", le 13 septembre. Il est probable qu'elle devienne une loi après que les pays de l'UE auront apporté leur contribution.
Selon le document, les règles pourraient réduire le coût des cyberincidents pour les entreprises de 290 milliards d'euros (289,8 milliards de dollars) par an, contre des coûts de mise en conformité d'environ 29 milliards d'euros.
Les fabricants devront évaluer les risques de cybersécurité de leurs produits et prendre les mesures appropriées pour résoudre les problèmes, précise le document.
Les entreprises devront notifier les incidents à l'ENISA, l'agence de cybersécurité de l'UE, dans les 24 heures dès qu'elles auront connaissance des problèmes, et prendre des mesures pour les résoudre.
Les importateurs et les distributeurs seront tenus de vérifier que les produits sont conformes aux règles de l'UE.
Si les entreprises ne s'y conforment pas, les autorités nationales de surveillance pourront "interdire ou restreindre la mise à disposition de ce produit sur le marché national, le retirer de ce marché ou le rappeler", précise le document.
Les entreprises qui enfreignent les règles peuvent se voir infliger des amendes allant jusqu'à 15 millions d'euros ou jusqu'à 2,5 % de leur chiffre d'affaires mondial total, le montant le plus élevé étant retenu, les amendes étant moins élevées pour les infractions moins graves.
Source : Document de la Commission européenne
Et vous ?
:fleche: Qu'en pensez-vous ?
Voir aussi :
:fleche: L'UE évolue vers un règlement relatif aux cryptomonnaies et attire l'attention avec l'abandon de la terminologie de bannissement de l'algorithme de preuve de travail : adoption tacite du bitcoin ?
:fleche: La loi européenne sur l'intelligence artificielle peut avoir un effet dissuasif sur les efforts en matière de logiciels libres, avertissent les experts de la Brookings Institution
:fleche: La Commission européenne critiquée et poursuivie pour avoir enfreint ses propres lois sur la protection des données, l'organisme de réglementation aurait transféré aux États-Unis des données
2 pièce(s) jointe(s)
]La proposition européenne de loi sur la cyber-résilience, une menace pour l'open source ? Oui,
La proposition européenne de loi sur la cyber-résilience, une menace pour l'open source ? Oui,
pour plusieurs acteurs qui indiquent que son application pourrait avoir un impact désastreux sur l'open source
La proposition de loi sur la cyber-résilience (CRA pour Cyber Resilience Act) de l'UE, qui vise à « renforcer les règles de cybersécurité pour garantir des produits matériels et logiciels plus sûrs », pourrait avoir des conséquences désastreuses pour les logiciels open source, selon des dirigeants de la communauté open source.
L'Europe part d'un constat :
Citation:
Les produits matériels et logiciels font de plus en plus l'objet de cyberattaques réussies, entraînant un coût annuel mondial estimé de la cybercriminalité à 5 500 milliards d'euros en 2021.
Ces produits souffrent de deux problèmes majeurs qui augmentent les coûts pour les utilisateurs et la société :
- un faible niveau de cybersécurité, reflété par des vulnérabilités généralisées et la fourniture insuffisante et incohérente de mises à jour de sécurité pour y remédier, et
- une compréhension et un accès insuffisants aux informations par les utilisateurs, les empêchant de choisir des produits dotés de propriétés de cybersécurité adéquates ou de les utiliser de manière sécurisée.
Alors que la législation existante sur le marché intérieur s'applique à certains produits contenant des éléments numériques, la plupart des produits matériels et logiciels ne sont actuellement couverts par aucune législation de l'UE traitant de leur cybersécurité. En particulier, le cadre juridique actuel de l'UE ne traite pas de la cybersécurité des logiciels non embarqués, même si les attaques de cybersécurité ciblent de plus en plus les vulnérabilités de ces produits, entraînant des coûts sociétaux et économiques importants.
Deux objectifs principaux ont été identifiés visant à assurer le bon fonctionnement du marché intérieur :
- créer les conditions pour le développement de produits sécurisés avec des éléments numériques en veillant à ce que les produits matériels et logiciels soient mis sur le marché avec moins de vulnérabilités et en veillant à ce que les fabricants prennent la sécurité au sérieux tout au long du cycle de vie d'un produit ; et
- créer des conditions permettant aux utilisateurs de prendre en compte la cybersécurité lors de la sélection et de l'utilisation de produits comportant des éléments numériques.
La loi proposée peut être décrite comme le marquage CE pour les produits logiciels et a quatre objectifs spécifiques. Notamment :
- veiller à ce que les fabricants améliorent la sécurité des produits contenant des éléments numériques dès la phase de conception et de développement et tout au long du cycle de vie ;
- assurer un cadre de cybersécurité cohérent, facilitant la conformité pour les producteurs de matériel et de logiciels ;
- améliorer la transparence des propriétés de sécurité des produits avec des éléments numériques, et
- permettre aux entreprises et aux consommateurs d'utiliser des produits contenant des éléments numériques en toute sécurité.
Le projet de loi comprend une évaluation d'impact qui indique que « pour les développeurs de logiciels et les fabricants de matériel, cela augmentera les coûts directs de conformité pour les nouvelles exigences de cybersécurité, l'évaluation de la conformité, la documentation et les obligations de déclaration ». Ce surcoût fait partie d'un coût total de mise en conformité, y compris la charge pesant sur les entreprises et les pouvoirs publics, estimée à 29 milliards d'euros, et les prix plus élevés qui en résultent pour les consommateurs. Cependant, les législateurs prévoient une réduction des coûts des incidents de sécurité estimés entre 180 et 290 milliards d'euros par an.
La question est cependant : comment les développeurs de logiciels libres peuvent-ils supporter le coût de la conformité, alors que le manque de financement est déjà un problème critique pour de nombreux projets ?
La perspective de la Fondation Eclipse
Mike Milinkovich, directeur de la Fondation Eclipse, s'est dit « profondément préoccupé par le fait que le CRA pourrait modifier fondamentalement le contrat social qui sous-tend l'ensemble de l'écosystème open source : des logiciels open source fournis gratuitement, à toutes fins, qui peuvent être modifiés et distribués ultérieurement gratuitement, mais sans garantie ni responsabilité envers les auteurs, contributeurs ou distributeurs open source. On peut raisonnablement s'attendre à ce que la modification légale de cet arrangement par le biais de la législation ait des conséquences imprévues sur l'économie de l'innovation en Europe ».
Il définit ce qu'il attend de la Fondation Eclipse, y compris l'élaboration, la documentation et la mise en œuvre de politiques et de procédures pour « chaque projet de la Fondation Eclipse ».
Milinkovich note également que le CRA vise à restreindre les « logiciels inachevés » afin qu'ils ne soient « pas disponibles sur le marché à des fins autres que les tests ». L'utilisation de versions intermédiaires et de logiciels en cours de développement intense est courante dans la communauté open source, et les licences ne sont actuellement pas limitées aux tests.
Citation:
Fondamentalement, le cœur de la législation proposée est d'étendre le régime de marquage CE à tous les produits comportant des éléments numériques vendus en Europe. Notre hypothèse basée sur le texte actuel est que ce processus sera appliqué aux logiciels open source mis à disposition sous des licences open source et fournis gratuitement, apparemment sous des licences qui déclinent toute responsabilité ou garantie. Nous sommes profondément préoccupés par le fait que le CRA pourrait modifier fondamentalement le contrat social qui sous-tend l'ensemble de l'écosystème open source : des logiciels open source fournis gratuitement, à toutes fins, qui peuvent être modifiés et redistribués gratuitement, mais sans garantie ni responsabilité envers les auteurs. , contributeurs ou distributeurs open source. On peut raisonnablement s'attendre à ce que la modification juridique de cet arrangement par voie législative ait des conséquences imprévues sur l'économie de l'innovation en Europe.
Sans une exemption plus claire pour l'open source, afin de se conformer à la législation, la Fondation Eclipse devra :
- Élaborer, documenter et mettre en œuvre des politiques et des procédures pour chaque projet de la Fondation Eclipse afin de s'assurer qu'elles sont conformes aux exigences du CRA notamment :
- Toutes les exigences de développement et de sécurité après la publication énoncées à l'annexe I, y compris la fourniture de mécanismes de notification et de mise à jour.
- Toutes les exigences relatives à la documentation de l'utilisateur énoncées à l'annexe II.
- Toute la documentation technique du produit indiquée à l'annexe V, y compris "... des informations complètes sur la conception et le développement du produit ... y compris, le cas échéant, des dessins et des schémas et/ou une description de l'architecture du système expliquant comment les composants logiciels s'appuient sur ou s'alimentent mutuellement et s'intègrent dans le traitement global.
- Pour chaque version de projet EF, préparer la documentation spécifique au projet requise par l'annexe V, y compris "... une évaluation des risques de cybersécurité contre lesquels le produit avec des éléments numériques est conçu, développé, produit, livré et maintenu...".
- Déterminer pour chaque projet s'il répond à la définition de « produit avec éléments numériques », « produit critique avec éléments numériques » ou « produit hautement critique avec éléments numériques ».
- Pour chaque projet qui est un "produit avec des éléments numériques", établir, compléter et documenter un processus d'auto-évaluation du marquage CE.
- Pour chaque « produit critique avec éléments numériques » ou « produit hautement critique avec éléments numériques », s'engager avec un organisme d'audit CE externe et compléter les processus supplémentaires requis pour obtenir l'approbation du marquage CE. Notez que nous ne savons pas exactement quels seraient les coûts en temps, en ressources et en argent pour mettre en œuvre ces processus d'audit externe. Notre hypothèse est qu'ils seraient substantiels.
- Il est également important de noter que dans la plupart des autres domaines réglementés par les marquages CE, ils sont effectués là où des normes, des spécifications et/ou des processus de certification bien connus sont en place. Ceux-ci ne sont pas en place pour la plupart des projets open source Eclipse Foundation. Cela pourrait augmenter considérablement les coûts et les risques associés à la conformité.
- Pour chaque version de projet, documenter que le processus de marquage CE pertinent consiste (comme décrit ci-dessus) en une déclaration de conformité UE rédigée et signée par un responsable de la fondation, puis le marquage CE est apposé et la documentation technique ainsi que la déclaration UE de conformité est mise à disposition pendant au moins 10 ans après la libération. Notez que nous estimons que chaque année, les projets de la Fondation Eclipse rendent disponibles plusieurs centaines de versions.
L'Open Source Initiative
L'Open Source Initiative (OSI) a soumis des commentaires à la Commission européenne demandant « des travaux supplémentaires sur l'exception Open Source aux exigences du corps de la loi ». L'OSI souhaite que la responsabilité de la conformité soit retirée à « tout acteur qui n'est pas un bénéficiaire commercial direct du déploiement ».
Simon Phipps, défenseur de l'open source et directeur de la norme OSI, a déclaré que la législation « pourrait nuire à l'open source » et que le texte actuel de la législation « causerait d'importants problèmes pour les logiciels open source », en partie à cause d'ambiguïtés dans le libellé, et en partie parce qu'il ne le fait pas, à savoir reconnaître « la manière dont les communautés open source fonctionnent réellement ».
Citation:
Nous reconnaissons que la Commission européenne a formulé une exception au considérant 10 pour tenter de garantir que ces dispositions n'affectent pas accidentellement les logiciels Open Source. Cependant, en s'appuyant sur plus de deux décennies d'expérience, nous, à l'Open Source Initiative, pouvons clairement voir que le texte actuel causera des problèmes considérables pour les logiciels Open Source. Les problèmes proviennent d'ambiguïtés dans la formulation et d'un cadrage qui ne correspond pas au fonctionnement réel des communautés Open Source et à la motivation de leurs participants.
Premièrement, pour que ceux qui distribuent des logiciels en tant que fonction communautaire puissent compter en toute confiance sur l'exclusion, celle-ci doit absolument être insérée en tant qu'article et le « devrait » doit être remplacé par « doit ».
Deuxièmement, étant donné que l'objectif est - ou devrait être - d'éviter de nuire aux logiciels Open Source, que la Commission européenne s'efforce de soutenir, cet objectif doit être énoncé au début du paragraphe comme justification, en remplacement de la formulation d'introduction sur la prévention des dommages. à la « recherche et à l'innovation » pour éviter de trop restreindre l'exception.
Troisièmement, la référence à « non commercial » comme qualificatif devrait être remplacée. Le terme « commercial » a toujours conduit à une incertitude juridique pour les logiciels et est un terme qui ne devrait pas être appliqué dans le contexte de l'open source car les utilisations commerciales spécifiques des projets open source par certains utilisateurs sont fréquemment déconnectées des motivations et de la rémunération potentielle de la communauté plus large de mainteneurs. Le logiciel lui-même est donc indépendant de son application commerciale ultérieure. Le problème n'est pas l'absence d'une taxonomie de « commercial », c'est le fait même de rendre « commercial » la qualification plutôt que, par exemple, « déploiement pour le commerce ». Ainsi, l'ajout d'une taxonomie de la commercialité n'est pas une solution. L'OSI serait heureux de collaborer sur de meilleures approches pour qualifier une exception.
D'autres réactions
Olaf Kolkman, conseiller exécutif de l'Internet Society, a également exprimé ses inquiétudes en disant que « le règlement devrait être modifié pour indiquer clairement que les logiciels produits sous une licence open source et distribués à but non lucratif sont hors de portée du règlement ».
C'est une question complexe car l'utilisation de logiciels open source dans les « éléments numériques » des produits est monnaie courante.
Brian Fox, ancien président du projet Apache Maven et maintenant CTO et co-fondateur de la société devops Sonatype, a déclaré que la législation pourrait rendre « Central, npm, PyPi et d'innombrables autres dépôts soudainement inaccessibles à l'Union européenne, ce qui serait désastreux, tant pour l'UE que pour l'écosystème dans son ensemble. Dans le même temps, il a déclaré que le projet de loi est « par ailleurs [un] texte législatif très admirable qui vise à renforcer la posture de cybersécurité dans les produits numériques d'une manière plus avancée que nombre de ses homologues ».
La question est maintenant de savoir si l'UE peut préserver la bonne intention de la législation sans les conséquences désastreuses redoutées par la communauté open source.
Sources : Cyber Resilience Act, Eclipse Foundation (1, 2), Internet Society, SonaType, The Document Foundation
Et vous ?
:fleche: Que pensez-vous de la proposition européenne sur la cyber-résilience notamment au niveau de ses objectifs annoncés ?
:fleche: Comprenez-vous les craintes des acteurs de l'open source ?
Debian déclare que la loi sur la cyber-résilience pourrait provoquer la disparition des petits projets
Debian affirme que la loi européenne sur la cyber-résilience pourrait provoquer la disparition de plusieurs petits projets de logiciels libres
dont dépendent de nombreuses distributions Linux
Le projet de loi européen sur la cyber-résilience (Cyber Resilience Act) continue de faire l'objet de contestation. Le projet Debian vient de publier une déclaration selon laquelle la législation européenne pourrait saper les efforts de la communauté du logiciel libre, notamment en obligeant de nombreuses petites entreprises et probablement tous les développeurs indépendants à mettre la clé sous la porte parce qu'ils ne peuvent tout simplement pas répondre aux exigences réglementaires. Les développeurs du projet Debian appellent à une exemption pour les petites entreprises et les entrepreneurs individuels, puisque de nombreuses distributions Linux dépendent de leur travail.
Le 19 juillet, le Parlement européen a voté en faveur d'un nouveau cadre juridique majeur en matière de cybersécurité : le Cyber Resilience Act (CRA). « Le projet de loi sur la cyber-résilience approuvé par la commission de l'industrie, de la recherche et de l'énergie vise à garantir que les produits dotés de fonctions numériques, tels que les téléphones ou les jouets, soient sûrs à utiliser, résistent aux menaces cybernétiques et fournissent suffisamment d'informations sur leurs propriétés en matière de sécurité », indique le communiqué de presse qui a suivi le vote. Cette déclaration presque banale reflète l'approche globale de la loi en matière de cybersécurité.
En effet, la loi européenne sur la cyber-résilience (CRA) est un cadre juridique qui décrit les exigences en matière de cybersécurité applicables aux produits matériels et logiciels comportant des éléments numériques mis sur le marché de l'Union européenne. La CRA imposera une série d'obligations aux fabricants et aux importateurs de "produits contenant des éléments numériques" (products with digital elements - PDE) : une catégorie qui est définie de manière large pour inclure à la fois les produits matériels et logiciels. Le texte final n'a pas encore été publié, mais les récentes discussions indiquent qu'il pourrait introduire les obligations suivantes :
- concevoir des PDE pour répondre à certaines exigences essentielles en matière de cybersécurité par l'évaluation des risques et la protection contre les vulnérabilités connues ;
- soumettre les PDE à des évaluations de conformité ;
- notifier les vulnérabilités identifiées (dans les 24 heures) à l'autorité nationale de cybersécurité compétente, à l'entité qui maintient le PDE vulnérable et, éventuellement, à l'ENISA (European Union Agency for Cybersecurity - Agence de l'Union européenne pour la cybersécurité) ;
- notifier les incidents de sécurité graves à l'ENISA, à l'autorité nationale de cybersécurité compétente et aux utilisateurs du PDE ;
- effectuer des contrôles préalables sur les PDE importés.
La législation a été accueillie favorablement par certains acteurs de l'industrie. « L'introduction de la CRA est opportune et vitale. Elle représente un effort concerté pour renforcer la résilience des produits numériques face aux menaces cybernétiques, ce qui exige une collaboration internationale et une vision stratégique. Cette initiative constitue une avancée significative dans le renforcement de la cyberdéfense de l'UE et dans l'affirmation de sa souveraineté numérique », a écrit un critique. Toutefois, dans la communauté du logiciel libre, elle soulève quelques préoccupations. Dans une déclaration adoptée et publiée mercredi, le projet Debian affirme :
Citation:
Envoyé par Projet Debian
Même si seules les "activités commerciales" entrent dans le champ d'application de la CRA, la communauté du logiciel libre - et par conséquent tout le monde - perdra un grand nombre de petits projets.
La CRA obligera de nombreuses petites entreprises et très probablement tous les développeurs indépendants à mettre la clé sous la porte parce qu'ils ne peuvent tout simplement pas répondre aux exigences imposées par la CRA.
Debian et d'autres distributions Linux dépendent de leur travail. Si elle est acceptée telle quelle, la CRA sapera non seulement une communauté établie, mais également un marché florissant. La CRA a besoin d'une exemption pour les petites entreprises et, au minimum, pour les entrepreneurs individuels.
Comme indiqué en haut, la CRA introduit un certain nombre de règles pour améliorer la résilience des produits contenant des éléments numériques face aux menaces cybernétiques. En cas de violation de ces règles, les contrevenants peuvent être frappés d'amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel. À en juger par les tendances émergentes, les analystes estiment que la législation n'affectera que les fournisseurs de logiciels commerciaux. Mais Debian considère la CRA comme un facteur qui pourraient limiter l'avancement des logiciels libres et entraver leur développement en tant que mouvement international.
Les sociétés qui développent des produits basés sur des projets internationaux de logiciels libres ou qui utilisent des bibliothèques de logiciels libres seront tenues pour responsables des problèmes de sécurité et de l'insuffisance des correctifs apportés aux vulnérabilités du code, même si ce code a été écrit par des passionnés d'autres pays. Par conséquent, l'apparition de risques commerciaux supplémentaire pourrait réduire l'attrait pour le développement de logiciels libres. Dans le même temps, les projets indépendants qui incluent du code provenant de fabricants de produits commerciaux peuvent également être affectés par des conséquences juridiques.
Par exemple, il existe une incertitude quant à la responsabilité dans les cas où le code open source écrit par une société commerciale peut être transféré à des projets tiers non commerciaux et utilisé dans des distributions Linux. La législation européenne introduit donc une responsabilité légale en cas de non-respect des exigences de sécurité, ce qui va à l'encontre de la responsabilité sociale de Debian de distribuer des logiciels pour n'importe quel usage et sans restrictions. Debian ne suit pas l'implication du code dans les projets commerciaux, l'emploi des développeurs et les sources de financement des développements fournis dans la distribution.
Pour Debian, le fait d'imposer les exigences spécifiées dans le projet de loi augmente les risques juridiques lors de l'utilisation de la distribution. Il existe un risque que les projets en amont cessent de fournir leur code par crainte de tomber sous le coup de la CRA et de l'application des sanctions associées. La CRA pourrait également rendre plus difficile le partage du code open source avec la communauté, en obligeant les développeurs à peser les implications juridiques de sa mise à disposition à la communauté open source. Selon de nombreux analystes, le texte actuel du projet de loi présent des risques majeurs pour la communauté du logiciel libre.
Pour rappel, les logiciels libres sont un pilier des logiciels modernes. Ils représentent généralement 70 à 90 % du code des applications Web et cloud. Ainsi, Synopsys, une société américaine spécialisée dans le développement de logiciels destinés principalement aux fabricants, a constaté que 98 % des applications analysées à l'aide de son service comprenaient des logiciels libres, et que 75 % de la base de code moyenne provenait de projets libres. Synopsys a également constaté qu'en moyenne, une application logicielle s'appuie sur plus de 500 dépendances open source. Cela met en évidence les défis importants qu'introduit la CRA pour toute l'industrie.
Par ailleurs, le projet de loi réduit l'attrait du processus de développement ouvert, puisque le travail est visible et transparent pour tout le monde, et que le code peut être utilisé pendant le processus de développement, permettant aux exigences de la législation de s'appliquer pendant que l'on travaille sur le produit. En revanche, les logiciels propriétaires sont développés derrière des portes closes et deviennent soumis à la loi lors de la publication finale. Pour toutes ces raisons, les développeurs du projet Debian souhaitent que le développement des logiciels libres soit exempté par la nouvelle législation et qu'elle ne s'applique qu'aux produits finaux.
Il est également proposé que les exigences de la CRA ne s'appliquent pas aux produits des entrepreneurs individuels et des petites entreprises, car ils ne seront pas en mesure de répondre à toutes les exigences prévues et seront contraints de fermer leur entreprise. Enfin, la déclaration publiée par les développeurs du projet Debian pointe du doigt également à la nature discutable de l'obligation de signaler les problèmes de sécurité à l'ENISA dans les 24 heures suivant l'identification d'un problème ou la réception d'informations sur une vulnérabilité. La centralisation de toute cette information pourrait introduire d'autres risques pour toute l'industrie.
Selon Debian, l'accumulation d'informations sur toutes les vulnérabilités qui n'ont pas encore été corrigées en un seul endroit peut entraîner de graves problèmes pour tous les utilisateurs en cas de fuite d'informations, de transfert d'informations à des agences de renseignement ou de compromission de l'ENISA.
Source : Debian
Et vous ?
:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous de la loi européenne sur la cyber-résilience ?
:fleche: Que pensez-vous des préoccupations de Debian à l'égard de cette législation ?
:fleche: Que pensez-vous des prétendus risques qu'introduit la législation pour les logiciels libres ?
:fleche: Le développement des logiciels libres doit-il bénéficier d'une exemption de la loi sur la cyber-résilience ?
Voir aussi
:fleche: La proposition européenne de loi sur la cyber-résilience, une menace pour l'open source ? Oui, selon des acteurs qui indiquent que son application pourrait avoir un impact désastreux
:fleche: La proposition de loi européenne sur la cyber-résilience pourrait avoir des conséquences inattendues pour l'écosystème Python, selon Deb Nicholson, Directeur exécutif de la Python Software Foundation
:fleche: Les appareils intelligents connectés à Internet devront se conformer à des règles strictes de l'Union européenne en matière de cybersécurité, sous peine de se voir infliger une amende ou d'être bannis
En quoi ça me concerne en tant que développeur de jeux?
Donc si je développe des jeux, je vais devoir faire certifier mon code? payer des centaines d'euros pour ça? J'espère que Unity va assumer le CE
1 pièce(s) jointe(s)
Loi européenne sur la cyber-résilience : qu'est-ce que cela signifie pour l'écosystème open source ?
Loi européenne sur la cyber-résilience : qu'est-ce que cela signifie pour l'écosystème open source ?
Un développeur analyse le nouveau texte du projet de loi
Le 20 décembre, le Comité des Représentants Permanents a confirmé l'accord sur le texte de compromis du projet de loi Cyber Resilience Act (CRA). Quelle est la portée de ces modifications sur les fournisseurs de logiciel open source ? Qu'en est-il des utilisateurs open source ? Analyse des implications pour le logiciel libre et open source (FOSS) du point de vue d'un développeur.
L'Europe part d'un constat :
Citation:
Les produits matériels et logiciels font de plus en plus l'objet de cyberattaques réussies, entraînant un coût annuel mondial estimé de la cybercriminalité à 5 500 milliards d'euros en 2021.
Ces produits souffrent de deux problèmes majeurs qui augmentent les coûts pour les utilisateurs et la société :
- un faible niveau de cybersécurité, reflété par des vulnérabilités généralisées et la fourniture insuffisante et incohérente de mises à jour de sécurité pour y remédier, et
- une compréhension et un accès insuffisants aux informations par les utilisateurs, les empêchant de choisir des produits dotés de propriétés de cybersécurité adéquates ou de les utiliser de manière sécurisée.
Alors que la législation existante sur le marché intérieur s'applique à certains produits contenant des éléments numériques, la plupart des produits matériels et logiciels ne sont actuellement couverts par aucune législation de l'UE traitant de leur cybersécurité. En particulier, le cadre juridique actuel de l'UE ne traite pas de la cybersécurité des logiciels non embarqués, même si les attaques de cybersécurité ciblent de plus en plus les vulnérabilités de ces produits, entraînant des coûts sociétaux et économiques importants.
Deux objectifs principaux ont été identifiés visant à assurer le bon fonctionnement du marché intérieur :
- créer les conditions pour le développement de produits sécurisés avec des éléments numériques en veillant à ce que les produits matériels et logiciels soient mis sur le marché avec moins de vulnérabilités et en veillant à ce que les fabricants prennent la sécurité au sérieux tout au long du cycle de vie d'un produit ; et
- créer des conditions permettant aux utilisateurs de prendre en compte la cybersécurité lors de la sélection et de l'utilisation de produits comportant des éléments numériques.
Élaboré sur la base de la stratégie de cybersécurité de l’UE de 2020, le CRA (Cyber Resilience Act) introduit des règles communes en matière de cybersécurité pour les fabricants et les développeurs de produits comportant des éléments numériques, couvrant à la fois le matériel et les logiciels. L’objectif de ce texte est de protéger les consommateurs et les entreprises des risques en matière de cybersécurité dans leur utilisation des matériels filaires et connectés, ainsi que des logiciels.
Le 15 septembre 2022, la Commission a présenté un premier projet qui a été soumis à l’examen du Parlement européen et du Conseil. Le 1er décembre 2023, Bruxelles que le Parlement européen et le Conseil étaient parvenus la veille à un accord sur la loi. Puis, le 20 décembre, le Comité des Représentants Permanents a confirmé l'accord sur le texte de compromis du projet de loi CRA.
La portée de ces modifications sur les fournisseurs de logiciel open source
Dans sa section 10, le texte traite principalement de l'open source. Voici une analyse du développeur Bert Hubert
L'activité commerciale, comment est-elle définie ?
Le CRA réglemente l'activité commerciale : « (10) Le présent règlement s'applique aux opérateurs économiques uniquement en ce qui concerne les produits comportant des éléments numériques mis à disposition sur le marché, donc fournis pour être distribués ou utilisés sur le marché de l'Union dans le cadre d'une activité commerciale ».
C’est un début encourageant pour l’open source. Si quelqu’un souhaite que le CRA réglemente les auteurs ou les entreprises open source, il doit d’abord établir que ce que vous faites est une « activité commerciale ». Or, les versions antérieures du CRA ne fournissaient pas de grandes indications sur ce qu’est une activité commerciale. Il y avait des inquiétudes justifiées quant au fait que si quelqu’un faisait suffisamment d’efforts, il pourrait prétendre que l’open source était aussi une « activité commerciale ».
Le CRA est très clair sur le fait que ce n’est pas uniquement une question d’argent. Par exemple, si vous essayez de faire « payer avec leurs données » aux utilisateurs comme condition d’utilisation de votre produit, c’est commercial. Ou, si vous associez votre produit open source à des services payants*:
- (10) une intention de monétiser, par exemple en fournissant une plate-forme logicielle à travers laquelle le fabricant monétise d'autres services, en exigeant comme condition d'utilisation le traitement des données à caractère personnel pour des raisons autres que exclusivement l'amélioration de la sécurité, de la compatibilité ou de l'interopérabilité du logiciel, ou en acceptant des dons dépassant les coûts associés à la conception, au développement et à la fourniture d'un produit comportant des éléments numériques.
N'est pas considéré comme une activité commerciale...
Dans le compromis final sur le CRA, de nombreuses précisions ont été ajoutées. Par exemple :
- (10c) .. la fourniture de produits logiciels gratuits et à source ouverte qui ne sont pas monétisés par leurs fabricants n'est pas considérée comme une activité commerciale.
- (10c) Le présent règlement ne s'applique pas aux personnes physiques ou morales qui contribuent au code source de produits gratuits et open source qui ne relèvent pas de leur responsabilité.
Donc si vous ne « monétisez » pas votre produit open source, vous pouvez arrêter de lire ici, le CRA ne s'applique pas à vous. Et si vous soumettez des PR, du code ou des correctifs à l’open source d’autres personnes, vous êtes également complètement tranquilles, peu importe ce qu’ils font.
Que se passe-t-il si quelqu'un vous soutient avec de l'argent, du matériel ou du code :
- (10c) le simple fait qu'un produit logiciel open source reçoive un soutien financier de la part des fabricants ou que les fabricants contribuent au développement d'un tel produit ne devrait pas en soi déterminer que l'activité est de nature commerciale.
- (10) L'acceptation de dons sans intention de réaliser un profit ne devrait pas être considérée comme une activité commerciale.
Que se passe-t-il si vous publiez régulièrement des versions logicielles sur lesquelles les gens comptent :
- (10c) En outre, la simple présence de rejets réguliers ne permet pas en soi de conclure qu'un produit est fourni dans le cadre d'une activité commerciale.
Que se passe-t-il si vous êtes une organisation open source à but non lucratif qui reçoit de l'argent (pour le développement) ?
- (10c). Aux fins du présent règlement, le développement de produits qualifiés de logiciels libres et open source par des organisations à but non lucratif ne devrait pas être considéré comme une activité commerciale pour autant que l'organisation soit créée de manière à veiller à ce que tous les bénéfices après coûts soient utilisés pour atteindre des objectifs à but non lucratif.
Que se passe-t-il si vous êtes une fondation open source à but non lucratif et que quelqu'un vous paie pour un support technique réel pour votre produit open source ?
- (10) La fourniture dans le cadre d'une activité commerciale peut être caractérisée non seulement par la facturation d'un prix pour un produit, mais également par la facturation de services d'assistance technique lorsque cela ne sert pas uniquement à récupérer les coûts réels.
Et si vous aviez acheté un produit provenant d'une entreprise très commerciale financée par du capital-risque, de sorte que le produit ait un historique commercial :
- (10c)Les simples circonstances dans lesquelles le produit a été développé, ni la manière dont le développement a été financé, ne devraient donc pas être prises en compte pour déterminer la nature commerciale ou non commerciale de cette activité.
Que se passe-t-il s’il y a des utilisateurs très commerciaux de votre open source qui gagnent de l’argent avec votre truc ?
- (10c) En outre, la fourniture de produits qualifiés de composants logiciels libres et à code source ouvert destinés à être intégrés par d'autres fabricants dans leurs propres produits ne devrait être considérée comme une mise à disposition sur le marché que si le composant est monétisé par son fabricant d'origine.
Que se passe-t-il si vous êtes une distribution Linux (comme Debian) hébergeant des tonnes d’open source d’autres personnes :
- (10e) Le seul fait d'héberger des produits sur des référentiels ouverts, y compris via des gestionnaires de packages ou sur des plateformes de collaboration, ne constitue pas en soi la mise à disposition sur le marché d'un produit comportant des éléments numériques.
Compte tenu de tout cela, presque tous les projets open source actuels devraient être épargnés. Il y a cependant des difficultés pour ceux qui réalisent des projets de « fauxpen source », ou pour ceux qui font des ventes commerciales régulières de choses fournies avec la source.
Qu’en est-il des utilisateurs open source ?
Le CRA reconnaît que les logiciels, ouverts ou fermés, sont constitués de composants et de bibliothèques, et elle a de beaux mots sur qui en est responsable : les personnes qui mettent les logiciels à disposition sur le marché dans le cadre d'une activité commerciale.
Mais la responsabilité s'arrête là : si quelqu'un utilise le logiciel open source dont vous êtes l'auteur, vous n'êtes en aucun cas responsable de son utilisation commerciale. Les personnes qui intègrent vos contenus doivent faire preuve de leur propre diligence raisonnable :
- (18 bis) Lors de l'intégration de composants provenant de tiers dans des produits pendant la phase de conception et de développement, afin de garantir que les produits sont conçus, développés et fabriqués conformément aux exigences essentielles prévues à l'annexe I du présent règlement, les fabricants devraient exercer une diligence raisonnable à l’égard de ces composants, y compris les composants logiciels libres et open source qui n’ont pas été mis à disposition sur le marché.
Cette posture contraste avec un précédent texte que dénonçait la Python Software Foundation. En effet, de nombreux éditeurs de logiciels modernes s'appuient sur des logiciels open source provenant de dépôts publics sans en avertir l'auteur, et certainement sans entrer dans une quelconque relation commerciale ou contractuelle avec lui. L'ancienne version indiquait que les auteurs de composants open source pourraient être légalement et financièrement responsables de la manière dont leurs composants sont appliqués dans le produit commercial d'un tiers.
Selon la Python Software Foundation, ce texte-là ne faisait aucune différence entre les auteurs indépendants qui n'ont jamais été payés pour la fourniture de logiciels et les grandes enseigne de la technologie qui vendent des produits en échange de paiements de la part des utilisateurs finaux. « Nous pensons que la responsabilité accrue devrait être soigneusement attribuée à l'entité qui a conclu un accord avec le consommateur. Nous nous joignons à nos collègues européens de la Fondation Eclipse et de NLnet Labs pour exprimer nos inquiétudes sur la manière dont ces politiques pourraient affecter les projets open source mondiaux. »
Quoiqu'il en soit, il est intéressant de noter que dans le cadre de cette diligence raisonnable, les intégrateurs (et les gouvernements !) pourraient initier ou sponsoriser des « attestations » du niveau de sécurité des composants open source. Ce serait un grand coup de pouce pour la sécurité open source :
- (10f) Les programmes d'attestation de sécurité devraient être conçus de telle manière que non seulement les personnes morales ou physiques développant ou contribuant au développement d'un produit qualifié de logiciel libre et à code source ouvert puissent initier ou financer une attestation, mais également des tiers, comme les fabricants qui intègrent de tels produits dans leurs propres produits, les utilisateurs ou encore les administrations publiques européennes et nationales.
Quelques éléments spécifiques sur la déclaration Debian
La déclaration Debian semble être basée sur une version antérieure du CRA.
Il est indiqué par exemple : «*Savoir si un logiciel est commercial ou non n'est pas réalisable, ni dans Debian ni dans la plupart des projets de logiciels libres*». En vertu de le CRA, il n'est pas nécessaire de comprendre cela pour Debian.
« Devoir obtenir des conseils juridiques avant de faire un cadeau à la société découragera de nombreux développeurs » - la version finale de le CRA est claire : si vous faites un cadeau, la CRA ne s'applique en aucun cas à vous. Il existe désormais une déclaration très claire à ce sujet.
« Imposer des exigences telles que celles proposées dans la loi rend juridiquement périlleux la redistribution de notre travail par d'autres » - le CRA a maintenant des notes spécifiques indiquant qu'une telle redistribution n'est pas couverte.
Aussi, Bert Hubert a déclaré « J'espère que le projet Debian le plus génial pourra examiner attentivement ce que dit la version actuelle du CRA, et peut-être proposer une nouvelle déclaration ».
Conclusion
Tout au long du processus CRA, divers instituts de l’UE et gouvernements des États membres ont été très réceptifs aux opinions de la communauté open source. De plus, le CRA crée virtuellement un nouveau processus par lequel l'industrie peut se réunir pour parrainer des documents de sécurité, des attestations, des audits ou même des travaux de sécurité sur des produits open source. La Commission européenne est habilitée à créer des modèles et des réglementations pour de telles procédures, et la contribution de la communauté open source serait sûrement utile pour en faire un succès.
Pour Bert Hubert, « si nous jouons bien les choses, l’open source pourrait enfin obtenir le soutien de l’industrie, car le CRA signifie que les personnes qui intègrent notre travail en sont désormais officiellement responsables ».
Source : EU Cyber Resilience Act, Bert Hubert
Et vous ?
:fleche: Que pensez-vous de l'analyse de Bert Hubert ?
:fleche: Vous semble-t-il y avoir des améliorations dans le projet de loi CRA par rapport à l'industrie de l'open source ? Dans quelle mesure ?
:fleche: De façon plus générale, quelles en sont les implications pour les développeurs et les professionnels de l'informatique ?