IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Stéphane le calme

11PARTAGES

14  0 
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é :
  1. 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
  2. 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 :
  1. 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
  2. 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 :
  1. 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 ;
  2. assurer un cadre de cybersécurité cohérent, facilitant la conformité pour les producteurs de matériel et de logiciels ;
  3. améliorer la transparence des propriétés de sécurité des produits avec des éléments numériques, et
  4. 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 :
  • É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.
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 ?

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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de juju26
Membre averti https://www.developpez.com
Le 01/01/2024 à 17:25
Bonjour,
Cela concerne quel type de logiciels / application ?
Parce que le risque de sécurité n'est certainement pas le même entre un jeux, un logiciel lamba en local (qui ne fait pas office de serveur), un pare-feu... ou encore une application en ligne...
Je n'ai pas trouvé de détails sur ce point.
Encore des lois usine à gaz qui impacteront uniquement les dev européens...
6  0 
Avatar de leyouki
Membre à l'essai https://www.developpez.com
Le 01/01/2024 à 15:05
Citation Envoyé par leyouki Voir le message
Une bonne âme pourrait pointer le rapport cité de synopsys sur la part de logiciel libre dans l'économie numérique actuelle ? Je ne le trouve pas. 🙏
Le rapport est présenté ici: https://www.synopsys.com/software-in...-analysis.html
et téléchargeable là: https://www.synopsys.com/content/dam...ossra-2023.pdf
3  0 
Avatar de totozor
Membre expert https://www.developpez.com
Le 03/01/2024 à 15:20
Citation Envoyé par bdr443 Voir le message
J'ai l'impression qu eles législateurs sont totalement déconnectés de la réalité et ont fait voter des lois sur des sujets qu'ils le maîtrisent pas.
N'est ce pas une sorte de vérité générale depuis quelques années?
Combien de ministres/députés travaillent dans un domaine dans lequel ils ont travaillé/fait leurs preuves/se sont dûment renseignés?
Et même quand c'est le cas ils travaillent en général sur des acquis devenus obsolètes, alors quand on parle d'un domaine qui évolue rapidement...
Mais ces gens sont supérieurement intelligents donc pourquoi auraient ils besoin de s'informer auprès de sachants?
2  0 
Avatar de HaryRoseAndMac
Membre extrêmement actif https://www.developpez.com
Le 28/01/2023 à 3:15
L'europe est entrain de sombrer dans un totalitarisme fou !

Il est plus que temps de mettre à un terme à la gouvernance de ces "dirigeants" qui n'en sont pas et de les faire destituer au plus vite.
1  0 
Avatar de totozor
Membre expert https://www.developpez.com
Le 30/01/2023 à 8:32
[Sarcasme]C'est du génie:
1. On impose une règlementation que seuls les grands peuvent se payer (on assure le maintien de ceux qu'on condamne en façade)
2. En imposant cette règlementation, on impose une certification - que nous allons assurer (On fait entrer des sous dans les caisses pour un service que personne ne demande)
3. Ce surcout sera escaladé au consommateur (nous) mais c'est pas grave on fait ça pour leur bien, ils vont être content

Voici ce que nous appelons le capitalisme moderne : faire payer des gens un service qu'ils n'ont jamais demandé pour sa propre survie et sous couvert de leur bien

T'es pas d'accord, on s'en fout, on te demande pas ton avis[/Sarcasme]
1  0 
Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 01/02/2023 à 18:32
Pour mettre le feu au debat, je suis plutot favorable a cette idee dans le fond. Et pourtant je fais 100% de mon dev en open-source autour d'Eclipse et d'autres projets de la Fondation (donc dans les contraintes dont parle Mike Milinkovich).
En fait, l'informatique atteint un age tres mature, et -comme prevu- a conquis le monde. Et donc, on commence a voir que des mauvais logiciels sont des sources de problemes pour la societe (eg des ransomwares qui bloquent les hopitaux a cause de failles logicielles). Au meme titre que les tuyaux de gaz, les bitumes des routes, les prises electriques, le legiciel arrive a etre critique au point de pouvoir etre un danger pour l'utilisateur et la societe s'il est trop mal fait. Ca parait donc interessant qu'une entitie politique censee representer le peuple decide de s'interesser au sujet en demandant des contraintes ou certification de securite aux fournisseurs de logiciels. L'objectif final semble etre une plus grande securite logicielle pour les citoyens et la societe. Si on peut le faire, pourquoi pas?
Apres, pour l'open source, il reste la question de qui est le fournisseur: est-ce que le fournisseur est l'auteur du code ou le consommateur qui l'embarque dans son application finale (potentiellement commerciale)? Mon experience avec l'OSS c'est qu'en realite, l'auteur de code OSS ne prend pas la responsabilite en cas de problemes et qu'il s'agit d'un partage de code au niveau R&D et non produit, cela n'empeche pas l'OSS d'etre de qualite produit, mais cela n'est pas une garantie qui est offerte sans contrepartie aux consommateurs, et le fait que le code soit ouvert est cense permettre aux consommateurs d'etablir la confiance dont ils ont besoin et eventuellement de faire certifier ce dont ils ont besoin pour leur business (apres tout, c'est le consommateur qui y gagne plus que le fournisseur, c'est normal que ce soit lui qui prenne en charge les frais de mise sur le marche). Je pense qui Mike et autres essayent de faire du lobbying pour rendre cette interpretation explicite dans la proposition de loi.
La ou la fondation et/ou la communaute Eclipse a un positionnement bancal, qui predate a cette proposition mais qui pese tres lourd ici, c'est qu'elle a tendance a se croire pour un editeur: c'est une fondation OSS mais elle ne se content pas de faire de la collaboration projet comme le fait eg le projet Linux: la fondation Eclipse heberge des quasi-produits comme l'Eclipse IDE, Glassfish, Temurin... et a ce titre, en se comportant comme un fournisseur de logiciels finaux, elle l'est peut-etre un peu. Avec quelques autres collegues influents chez Eclipse, on se demande et on demande a la communaute Eclipse en general, si le modele de fournir des binaires aux utilisateurs n'est pas en soit un probleme. Rester au niveau "le projet met a dispo les sources, aux consommateurs de builder" comme le font Gnome ou le kernel Linux presente au final des avantages sur la responsabilisation des consommateurs vis-a-vis de l'open-source: en devant builder eux-memes, il devient clair qu'ils ont interet a contribuer, et qu'ils deviennent responsable de la qualite du resultat. Ca remet les choses au clair tant au niveau organisationnel qu'au niveau juridique.

Par contre, j'imagine que la proposition de loi en l'etat a de claires lacunes qui devront etre corrigees. Il est beaucoup plus dur d'ecrire une bonne loi que d'ecrire du code. Il est normal que des critiques soient fait pour proteger les bases du domaines, que la societe civile et la sphere politique n'ont pas forcement a leur connaissance immediate. Mais j'apprecie l'intention de cette proposition de loi.
1  0 
Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 01/02/2023 à 18:41
Et j'en rajoute une couche: de part le code source ouvert et accessible, l'open-source a en fait une avance certaine sur le code close-source. Il peut etre audite et certifie sans devoir creer de documentation technique intermediaire, il est naturellement plus securise de part son exposition a plus de lecteurs. Donc ce CRA pourrait meme etre un avantage competitif de l'OSS par rapport au code ferme.
1  0 
Avatar de denisys
Membre chevronné https://www.developpez.com
Le 29/12/2023 à 16:36
Il devient de plus en plus urgent, de ce débarrassé de la dictature de l'Union européenne !!!!
4  3 
Avatar de leyouki
Membre à l'essai https://www.developpez.com
Le 01/01/2024 à 13:36
Une bonne âme pourrait pointer le rapport cité de synopsys sur la part de logiciel libre dans l'économie numérique actuelle ? Je ne le trouve pas. 🙏
1  0 
Avatar de totozor
Membre expert https://www.developpez.com
Le 02/02/2023 à 8:46
J'aime ton point de vue mais je me pose des questions en tant que néophyte
Citation Envoyé par Mickael_Istria Voir le message
Apres, pour l'open source, il reste la question de qui est le fournisseur: est-ce que le fournisseur est l'auteur du code ou le consommateur qui l'embarque dans son application finale (potentiellement commerciale)?[...]l'auteur de code OSS ne prend pas la responsabilite [...], cela n'empeche pas l'OSS d'etre de qualite produit, mais cela n'est pas une garantie[...] aux consommateurs, [...] permettre aux consommateurs d'etablir la confiance [...] de faire certifier
Désolé d'avoir haché le texte mais ça permet de mettre en avant ce qui me semble l'articulation de la reflexion.
Si je suis le consommateur de l'open source, je deviens le fournisseur d'un service couvert par la proposition.
Donc je vais être audité sur mon produit et je vais devoir justifier de la qualité de mon socle l'open source.
Et là il y a quelques choix :
- je t'imposes un audit pour me couvrir du risque que ton code représente
- je prends la responsabilité de l'analyse et de la garantie de la certification de ton code (ça coute et je ne vais probablement jamais accepter d'assumer ça)
- je te demande le certificat au moment où j'utilise ton code
- je n'utilise plus ton code et je vais payer un autre pour le service et le certificat

D'un point de vue capitaliste je ne gagne rien à payer pour la certification d'un produit récupérer.
Si je veux rendre ça "rentable" je t'achètes pour gagner le bénéfice de mon investissement.
Donc à la fin, on pousse (passivement) l'Open Source à disparaitre par impuissance face au système certificatif.

Citation Envoyé par Mickael_Istria Voir le message
il devient clair qu'ils ont interet a contribuer, et qu'ils deviennent responsable de la qualite du resultat. Ca remet les choses au clair tant au niveau organisationnel qu'au niveau juridique.
Dans l'industrie, un risque on le tue (s'il est technique on s'assure de le faire disparaitre), on le transfert (technique de la patate chaude) ou on l'assure (je paye une assurance qui payera à ma place le jour où il s'avère).
Si le fonctionnement est identique, je n'ai pas intérêt à prendre en charge le risque lié au travail d'un autre (sauf s'il est tellement petit que ça ne me coute - virtuellement - rien)
Citation Envoyé par Mickael_Istria Voir le message
Il peut etre audite et certifie sans devoir creer de documentation technique intermediaire, il est naturellement plus securise de part son exposition a plus de lecteurs. Donc ce CRA pourrait meme etre un avantage competitif de l'OSS par rapport au code ferme.
Dans l'industrie un auditeur ne certifiera (il prend une responsabilité juridique quand il le fait) jamais un objet s'il n'est pas décrit par une doc technique.
Les auditeurs que j'ai croisé n'aiment pas ce qui est naturel, ils aiment ce qui est écrit.
Il y a pas longtemps on s'est fait épinglé parce qu'un opérateur ne respectait pas la procédure mais avait une attitude plus sécurisante qu'elle. (Ce n'est pas l'opérateur qui se fait épingler mais le responsable de la procédure)
0  0