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 :
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é :
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 :
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.
- 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.
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 :
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 ».
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.
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.
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 ?
Que pensez-vous de la proposition européenne sur la cyber-résilience notamment au niveau de ses objectifs annoncés ? Comprenez-vous les craintes des acteurs de l'open source ? 
Envoyé par leyouki
