Après avoir initialement été ignorés, les défenseurs des logiciels libres et open source ont obtenu de ne pas avoir à respecter les mêmes règles et normes que ceux susceptibles de devoir estampiller leurs produits commerciaux de la « norme CE ».
La Commission du marché intérieur et de la protection des consommateurs (IMCO) du Parlement européen a accepté d'exclure les logiciels libres, exception faite de « l'exercice d'une activité commerciale », du projet de Loi sur la cyberrésilience (ou Cyber Resilience Act, CRA), se félicite la Free Software Foundation Europe (FSFE).
« La commission du marché intérieur et de la protection des consommateurs a soutenu notre demande et voté pour la protection des développeurs de logiciels libres dans la loi sur la cyber-résilience », précise dans le communiqué Alexander Sander, consultant de la FSFE.
Il note cela dit que la Commission de l'industrie, de la recherche et de l'énergie (ITRE), « compétente au fond », est maintenant appelée à suivre ce vote, avant que le trilogue avec le Parlement, le Conseil et la Commission européenne ne parvienne à un accord final.
« Seuls les logiciels libres mis à disposition sur le marché dans le cadre d’une activité commerciale sont couverts, l’évaluation devant se faire produit par produit en tenant compte du modèle de développement et de la phase d’approvisionnement du produit libre », explique Euractiv, qui qualifie ce champ d’application du règlement de « sujet de discussion très controversé » :
« L’exemple donné pour un cadre non commercial est celui d’un modèle entièrement décentralisé dans lequel aucune entité commerciale n’exerce de contrôle sur ce qui est accepté dans la base de code du projet. »
Un coût annuel estimé à 5,5 milliards d’euros
Soulignant que les produits matériels et logiciels font de plus en plus l’objet de cyberattaques réussies, « entraînant un coût annuel de la cybercriminalité estimé à 5,5 milliards d’euros », cette proposition de règlement relatif aux exigences de cybersécurité applicables aux produits comportant des éléments numériques entend répondre à deux « problèmes majeurs » :
- un faible niveau de cybersécurité, qui se traduit 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 ;
- les utilisateurs ne comprennent pas suffisamment les informations et n’y ont pas accès, ce qui les empêche de choisir des produits possédant des propriétés adéquates en matière de cybersécurité ou de les utiliser de manière sécurisée.
Notant que la plupart des produits matériels et logiciels ne sont actuellement couverts par aucune législation de l’UE traitant de leur cybersécurité, le CRA entend définir « deux objectifs principaux » pour assurer le bon fonctionnement du marché intérieur :
- créer les conditions nécessaires au développement de produits sûrs comportant 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 veiller à ce que les fabricants prennent la sécurité au sérieux tout au long du cycle de vie d’un produit ;
- créer des conditions permettant aux utilisateurs de tenir compte de la cybersécurité lors de la sélection et de l’utilisation de produits comportant des éléments numériques.
Quatre objectifs spécifiques ont en outre été définis :
- veiller à ce que les fabricants améliorent la sécurité des produits comportant des éléments numériques depuis la phase de conception et de développement et tout au long du cycle de vie ;
- garantir un cadre cohérent en matière de cybersécurité, en facilitant le respect des règles par les producteurs de matériel et de logiciels ;
- améliorer la transparence des propriétés de sécurité des produits comportant des éléments numériques ;
- permettre aux entreprises et aux consommateurs d’utiliser des produits comportant des éléments numériques en toute sécurité.
Une épée de Damoclès sur le logiciel libre
Ce projet imposerait dès lors aux fabricants (d'objets connectés par exemple) de notifier à l’Agence de l’Union européenne pour la cybersécurité (ENISA) s’ils ont connaissance d’une vulnérabilité activement exploitée :
« Dans le nouveau texte, cette obligation de notification ne s’applique que si un acteur illégal ou malveillant est à l’origine du piratage. En d’autres termes, si le piratage provient d’une autorité publique telle qu’un organisme chargé de l’application de la loi, il n’y aurait pas d’obligation de le signaler. »
Euractiv relève cela dit que les PME « ont été exemptées de l’alerte précoce si elles ne disposent pas de capacités suffisantes ».
Fin avril, plusieurs organisations représentatives des développeurs et défenseurs des logiciels libres et Open Source Software (FLOSS) avaient co-signé une lettre ouverte exprimant leur « vive inquiétude » au sujet du projet de règlement, qualifié par l'association April d' « épée de Damoclès sur le logiciel libre », et pointé l'absence de consultation des communautés FLOSS, alors même que « les logiciels libres représentent en Europe plus de 70 % des logiciels présents dans les produits contenant des éléments numériques » :
« Rien qu’en Europe, nous représentons 30 milliards d’euros de chiffre d’affaires direct et environ 100 milliards d’euros d’impact économique. Il est donc essentiel que toute législation qui a un impact sur l’industrie du logiciel prenne en compte les besoins et les perspectives uniques des logiciels libres, ainsi que nos méthodologies modernes utilisées pour créer les logiciels. »
De fait, les logiciels open source n'étaient que marginalement mentionnés, pages 30 et 31 de la deuxième partie de l'analyse d'impact du projet de loi, qui ne faisait par contre aucune mention des logiciels libres.
Une méthodologie basée sur un système de « norme CE »
La Commission voulait en effet « imposer de manière verticale une méthodologie basée sur un système de "norme CE", adossée à une très forte responsabilité de celles et ceux qui produisent du code et de celles et ceux qui le diffusent » :
« Toute personne produisant ou diffusant du code serait ainsi individuellement responsable de la sécurité de ce code, dans le cadre des obligations découlant du règlement. Or, la plupart des logiciels libres sont développés avec des moyens dérisoires, par des bénévoles ou de petites structures, et n’ont pas la capacité financière et humaine de mettre en œuvre les processus lourds et complexes qu’induirait le projet de règlement, notamment en termes de certification. »
Les signataires déploraient que le Cyber Resilience Act « risquerait d'avoir un effet dissuasif délétère sur le développement et l'utilisation des logiciels libres en Europe et sans doute, par répercussion, à une échelle plus globale », comme le résumait le communiqué d'April :
« On imagine ainsi aisément que des entreprises puissent d'elles-mêmes exclure le recours à des composants libres, tiers, de leurs propres solutions au profit de logiciels privateurs, préférant laisser à l'éditeur le soin de se conformer aux obligations du règlement, plutôt que de se charger elles-mêmes d'une maintenance pro-active de ces composants tiers. »
Quid des FLOSS développés le week-end dans un garage ?
« L'objectif du CRA est louable : améliorer la cybersécurité des produits qu'on achète », nous explique l'un des signataires, Gaël Blondelle de la Fondation Eclipse, à mesure que « la cible première est la "fameuse" caméra qui intègre de l'open source, est diffusée avec admin/admin comme mot de passe par défaut, et devient un bot relayant toutes sortes d'attaques, ou capte des images personnelles ».
« Nous soutenons qu'il faut que la charge de conformité du Cyber Resilience Act s'applique à ceux qui monétisent l'open source, pas à ceux qui développent et/ou distribuent les logiciels open source gratuitement », précise-t-il cela dit :
« Mais dans le CRA, la commission a étendu le scope à tout élément logiciel. Et pour l'open source, malgré un Recital qui vise à exclure l'open source, il s'avère qu'il n'exclut en fait que les hobbyistes qui font du free software le week-end dans le garage. »
L'ancien vice-président de l'association April Sébastien Dinot évoque de son coté le cas des smartphones, « car ils illustrent bien la complexité du sujet » :
« La plupart d'entre eux tournent en effet sur Android et ce projet est libre. Du coup, si le CRA exclut globalement le logiciel libre, il exclut Android, alors que ce système est certainement l'une des cibles prioritaires. Les auteurs du CRA ne peuvent donc pas exclure le logiciel libre. »
Commentaires (11)
#1
Comme quoi il y a un vrai problème avec le financement de l’écosystème libre, beaucoup d’entreprises construisent leur applications sur tout un tas de briques libre, mais ne participent pas à leur développement.
J’aimerais voir plus d’entreprise prendre leurs responsabilités et participer, ne serait-ce que financièrement aux projets qu’elles utilisent, alors peut-être qu’on aurait moins de failles.
#1.1
C’est bel est bien la réflexion à avoir. En 2023 on ne peux plus se permettre de vendre un produit sans assurer que ses fournisseurs de composant logiciel ou matériel assurent un minimum de suivi des vulnérabilités. Et c’est bien les entreprises marchandes qui doivent être mises à contribution pour soutenir financièrement leurs fournisseurs qu’ils soient libre ou pas.
Imaginer son routeur, sa TV, ses cameras et i-devices ouverts au 4 vents parce qu’un composant est une véritable passoire et que personne n’est en mesure de combler la faille par manque de moyens humain ou financier (les deux sont liés) n’est plus acceptable.
Qu’un composant aussi trivial que Log4J se retrouve partout sans que les vendeurs de logiciels ou de matériel en aient conscience, avec une vulnérabilité très impactante et que de l’autre coté de la chaine la fondation Apache n’ait pas les moyens financier pour mettre plus de deux ressources humaines sur le traitement de log4J est effarent de mon point de vue.
#2
exempter des trucs comme android, chrome ou elasticsearch… ca a du sens.
ou pas.
#3
Normer c’est très bien, mais le parlement Européen oublie qu’il existe des PME et TPE et que à leur niveau monter un dossier CE ou ISO est un cauchemar.
Ce que j’en sais, il y a eu des dérives dans le passé des organismes notifiés (auditeurs), une purge a eu lieue depuis (80 > 30 ON), il y a un énorme goulot d’étranglement.
L’autre effet de bord dans l’industrie est l’appauvrissement des gammes, qui a envie d’investir des équipes et des moyens pour certifier X ou Y produit.
Comme évoqué, le cas Android, il y a une granularité de la responsabilité à trouver entre taille d’entreprise et licence.
Bref, on est pas sorti de la technocraparty.
#3.1
+1
Ce projet de loi va noyer les TPE et PME sous une montagne de bureaucratie.
Le temps passé à remplir de la paperasse ne sera pas passé à innover et faire de la sécurité.
#4
Au moins c’est clair, les petits joueurs n’ont plus leur place dans l’U.E. … allez dégagez les nuls, on prendra des solutions US.
#5
Si je comprends bien : les logiciels libres sont exantés par défaut, mais s’ils sont intégrés à une offre commerciale, il faut le certifier, c’est bien ça ?
Si j’ai bien compris, on va avoir des logiciels libres qui vont être certifiés, et donc utilisés par l’industrie, et d’autre mis sur le carreau parce que personne n’aura financé leur certification.
Qu’en est-il de l’évolution des logiciels en question et de leir certification ? Il n’y a qu’une seule version de certifiée et ensuite on doit refaire la certification à chaque version (donc bonjour la complexité pour la maintenance) ?
#6
C’est une loi écrite par le release management d’une banque d’il y a 20 ans…
#7
Faut-il se réjouir ? J’avoue que je ne sais pas.
Sur le principe, je ne suis pas contre le fait que le logiciel libre soit exempté de ces obligations. Bien au contraire même.
Mais j’ai très peur des effets de bord :
Bref, énormément de questions, potentiellement beaucoup de répercussions. A prendre avec des pincettes tout ça !
#8
Ce qui est libre dans les smartphones Android c’est Android Open Source Project (AOSP).
Android, lui n’est pas libre, car Google ajoute sa surcouche propriétaire à AOSP (Google Mail, Moteur de recherche Google, …..).
C’est pour cela que Android est interdit d’exportation en Chine, mais pas AOSP qui est libre.
#8.1
GSF n’est pas libre, Android est libre.