Discussion :

[Sandra Coret]

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 ?

Qu'en pensez-vous ?

Voir aussi :

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 ?

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

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

[pierre-y]

Amazon qui arose généreusement le parlement européen mais qui veut quand même cartographié nos baraque, ça va se situer ou?

[totozor]

Je pensais que cette loi servait surtout à "protéger" les particuliers mais :

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.

Les entreprises se font vraiment piratées via leur électroménager connecté?
Je sais par exemple que nous avons plusieurs réseaux dans mon entreprise, je serais très surpris que les télé promotionnelles ou les outils de saisie sans accès sécurisé soient reliée au réseau de prodution.

[mith06]

L'analyse systématique des messages privés à la recherche de matériel d'abus sexuel d'enfants (CSAM) est-elle compatible avec leurs règles sur la cybersécurité?

https://www.developpez.com/actu/3334...n-des-enfants/

[Stéphane le calme]

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 :

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 ?

[HaryRoseAndMac]

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.

[totozor]

[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]

[Mickael_Istria]

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.

[Mickael_Istria]

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.

[totozor]

J'aime ton point de vue mais je me pose des questions en tant que néophyte

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.

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)

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)

[Mickael_Istria]

Dans le cas de l'OSS...

- je t'imposes un audit pour me couvrir du risque que ton code représente

Tu ne peux rien imposer à l'auteur d'un code. Tu peux négocier, embaucher, acheter... mais sans un contrat qui donne des contreparties, l'utilisateur n'a pas d'influence forte sur l'auteur.

je te demande le certificat au moment où j'utilise ton code

Si un projet OSS a déjà été certifié (et que le commanditaire de la cetification le permet), alors ça ne pose pas de problème pour le projet de le partager. Au contraire, cette certification devient un label de qualité, l'avoir est un avantage concurrenciel. Donc les projets cetifiés seront finalement assez contents de l'exhiber pour gagner en crédibilité.

- 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)-

Certains n'auront pas le choix. Des projets sont tellement ancrés qu'ils sont quasi irremplaçables et qu'il faudra bien qu'un ou plusieurs consommateurs s'organisent pour le certifier quand le CRA sera la.

- je n'utilise plus ton code et je vais payer un autre pour le service et le certificat

Ce n'est pas forcément toujours plus rentable que de payer un audit.
Mais concrètement, ça consolide aussi des business-model OSS: le projet est OSS communautaire, non certifié et un éditeur contributeur peut décider de prendre une version et de la certifier et de la vendre avec la certif. C'est déjà le business-model de Red Hat (mon employeur) par exemple, qui vend par exemple Red Hat Enterprise Linux (RHEL) qui est un rebuild d'une ancienne version testée, stabilisée, documentée... de Fedora (qui est communautaire) et les gens paye Red Hat pour ce bonus de qualité. De la même manière, Red Hat payera surement la certification pour RHEL ou des parties de Fedora pour avoir la possibilité de continuer à vendre RHEL; et les gens qui doivent utiliser un OS certifié viendront donc préférer encore plus RHEL -et payer Red Hat- que de prendre d'autres distros qui ne sont pas certifiées.

Mais aussi, tu oublies des possibilités:
- Le consommateur paye l'audit/la certif de la brique OSS dont il a besoin et la contribue au projet => Le projet développe un avantage compétiftif et gagne alors en pérennité ce qui peut rendre le coût de l'audit rentable à moyen terme
- Plusieurs consommateurs s'accordent à partager les frais de la certif pour en bénéficier tous, de la même manière qu'on partage déjà le développement, les coûts d'infra... Les fondations ou consortiums open-source peuvent être les bons acteurs pour centraliser ça. => Le coût de la certif est partagé car le code est partagé, l'OSS a alors un avantage car elle permet ça plus facilement que du code fermé ou du dev interme.

D'un point de vue capitaliste je ne gagne rien à payer pour la certification d'un produit récupérer.

Si tu n'as pas le choix et qu'il ne te faut que du certifié, tu te poseras la question de comment être le plus rentable possible. Payer un audit sur un code externe que tu ne maintiens pas sera probablement moins cher que de payer un même audit sur un code sur un code que tu maintiens en interne; et restera potentiellement moins cher que de payer des licences... Ca dépendra des cas, mais je pense qu'en général l'approche OSS sera en fait encore plus rentable car les coûts d'audit peuvent aussi être partagés.

Si je veux rendre ça "rentable" je t'achètes pour gagner le bénéfice de mon investissement.

Tu ne peux pas acheter du code OSS, il est déjà existant et peut continuer tout seul. Aussi, revenons à l'objectif: ton objectif n'est pas de collectionner les certifications pour les revendre, d'ailleurs en l'état ce n'est pas clair si la certif est attachée à une brique logicielle, à un ensemble, si elle est la propriété de son acheteur (ce qui serait dommage) ou un bien commun que n'importe qui peut réutiliser si il utilise ce même logiciel... Selon ces détails, ça peut changer beaucoup de choses sur le modèle de "rentabilité"; mais quoi qu'il en soit, par rapport à l'état actuel, ce sera jamais rentable: on parle de forcer des coûts supplémentaires au développement, pas de générer plus de business. C'est fondamentalement à perte financièrement. Mais augmenter les coûts de production peut avoir des effets intéressant même sur la rentabilité: ça incite à produire moins, à produire mieux, plus durable.

Donc à la fin, on pousse (passivement) l'Open Source à disparaitre par impuissance face au système certificatif.

Je ne suis toujours pas convaincu que l'OSS soit plus impuissant que le propriétaire par rapport au système certificatif. Pour rappel, le dev OSS représente des millions de développeurs (~12% de l'ensemble de l'activite IT en France), est en croissance plus rapide que la moyenne du secteur; c'est pas 3 geeks dans un garage qui sont démunis, c'est 12% de tous les investissement logiciels du moment, avec un perspective à 15% d'ici 5 ans ( https://cnll.fr/media/2019_CNLL-Synt...urce-Study.pdf ), c'est un pan entier des l'industrie, qui pourra payer des certifs aussi bien voire mieux que pas mal de "petites" boites de logiciels propriétaires.

[totozor]

Merci, j'y vois un peu plus clair

Aussi, revenons à l'objectif: ton objectif n'est pas de collectionner les certifications pour les revendre

Mon objectif est de certifier ce que je veux vendre pour pouvoir le faire.
Dans l'industrie, on doit collectionner les certifications de nos fournisseurs parce que pour certifier mon produit je dois certifier mon travail, celui de mes fournisseur et certains de mes outils.
En pratique, il existe d'autres solutions mais elles sont tellement périlleuses et couteuses qu'on les évites tant que possible.

Cette mécanique fait, qu'a partir d'une taille critique, les entreprises industrielles ont besoin de ces certifications pour maintenir leur clientèle. Certification plus ou moins accompagnée et soutenue par certains clients.

Je trouve cool que l'Open Source s'insert dans le monde plus facilement que certaines activités industrielles.

[Mickael_Istria]

Il y a pas mal d'articles et de ressources qui arrivent a ce sujet. La plus proche de notre discussion est

[Mathis Lucas]

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 :

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 ?

Quel est votre avis sur le sujet ?
Que pensez-vous de la loi européenne sur la cyber-résilience ?
Que pensez-vous des préoccupations de Debian à l'égard de cette législation ?
Que pensez-vous des prétendus risques qu'introduit la législation pour les logiciels libres ?
Le développement des logiciels libres doit-il bénéficier d'une exemption de la loi sur la cyber-résilience ?

Voir aussi

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

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

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

[denisys]

Il devient de plus en plus urgent, de ce débarrassé de la dictature de l'Union européenne !!!!

[irrmichael]

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

[leyouki]

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. 🙏

[Stéphane le calme]

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 :

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.

É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 1^er 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 ?

Que pensez-vous de l'analyse de Bert Hubert ?
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 ?
De façon plus générale, quelles en sont les implications pour les développeurs et les professionnels de l'informatique ?

[leyouki]

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

[juju26]

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...