Les législateurs européens se rapprochent d’un accord sur le règlement sur la cyberrésilience (Cyber Resilience Act) en ce qui concerne les logiciels open source et la période de maintien en conditions opérationnelles.
Le Cyber Resilience Act est une proposition législative qui introduit des exigences de sécurité pour les appareils connectés. Le projet de règlement se trouve à présent dans la dernière étape du processus législatif européen : les négociations interinstitutionnelles (aussi appelées trilogues), au terme desquelles le Parlement européen, le Conseil et la Commission s’accorderont sur un texte final.
Selon les textes de compromis consultés par Euractiv, les législateurs de l’UE s’approchent d’un compromis sur deux parties importantes du texte : la manière de règlementer les logiciels open source et la définition de la période de maintien en conditions opérationnelles, au cours de laquelle les fabricants devront fournir les mises à jour de sécurité.
Si cet accord est confirmé, ces parties du texte seront probablement approuvées au niveau politique lors de la prochaine session de trilogue qui aura lieu le 8 novembre.
Logiciels open source
L’un des principaux points de discussion du projet de loi concerne les logiciels open source, qui sont un moteur essentiel de l’innovation dans le domaine numérique. Les négociateurs de l’UE discutent actuellement d’une approche basée sur un compromis initialement diffusé le 20 octobre.
Si la caractéristique des logiciels open source est qu’ils sont généralement issus d’un travail en collaboration, il existe différentes façons pour les titulaires de droits d’exercer un contrôle sur ce qui est accepté dans le code final et sur la manière dont il est commercialisé.
Ces deux facteurs sont essentiels pour déterminer dans quelle mesure les logiciels open source peuvent se conformer aux exigences du futur règlement sur la cybersécurité. C’est pourquoi les législateurs européens ont conçu une approche à plusieurs niveaux avec des obligations proportionnées.
Une entité commerciale qui développe et contrôle seule un logiciel open source intégré à ses produits doit se conformer à toutes les obligations du règlement, y compris les exigences de base, la documentation des spécifications techniques (surnommées « specs »), le marquage de conformité (CE) et la surveillance du marché.
Un scénario plus complexe concerne les situations où le logiciel est développé en collaboration sous l’égide d’organisations à but non lucratif qui développent des logiciels open source sous licence. L’idée ici est d’introduire un régime moins contraignant avec des obligations spécifiques.
Les exigences adaptées à de telles organisations comprennent la mise en place et la promotion d’un processus de traitement des failles de sécurité, y compris le déploiement impératif de correctifs de sécurité et la notification des failles de sécurité activement exploitées.
Les organisations développant des logiciels open source sous licence ne seront pas soumises à des amendes, car l’attribution de la responsabilité pourrait s’avérer assez complexe, et leurs logiciels n’auront pas à présenter le marquage CE pour prouver qu’ils respectent les règles de l’UE.
De plus, les logiciels développés en collaboration sans qu’une entité unique décide de ce qui est accepté dans le code final et dont le logiciel est mis sur le marché sans but lucratif sont exclus du champ d’application du règlement.
En outre, le texte précise que les contributions individuelles des développeurs à des projets open source ne sont pas considérées comme une « activité de production », tandis que les entités hébergeant des logiciels open source dans leurs référentiels ouverts ne sont pas considérées comme des distributeurs si le logiciel est fourni sous une licence libre.
Le texte actuel autorise la Commission européenne à adopter des textes juridiques secondaires pour établir les lignes directrices en ce qui concerne les programmes d’attestation de sécurité.
Ces programmes sont pensés comme un moyen pour encourager les développeurs et les utilisateurs de logiciels open source à évaluer la conformité des produits au regard de la législation européenne et pour aider les fabricants à intégrer des composants open source dans leurs produits.
Maintien en conditions opérationnelles
Tout au long de la période de maintien en conditions opérationnelles, les fabricants doivent assurer la résolution des failles de sécurité, notamment en déployant des correctifs de sécurité dans les meilleurs délais. La proposition initiale de la Commission prévoyait que la période de maintien en conditions opérationnelles aurait dû couvrir la durée de vie prévue du produit ou cinq ans, la durée la plus courte étant retenue.
Le Parlement européen et le Conseil ont supprimé cette limite de cinq ans, donnant ainsi aux fabricants une plus grande marge de manœuvre afin qu’ils puissent rester compétitifs sur cet aspect. Un texte de compromis daté du 24 octobre et consulté par Euractiv a réintroduit le délai de cinq ans, mais sous une forme différente.
Le texte précise que « sauf s’il est prévu que le produit comportant des éléments numériques soit utilisé pendant moins de cinq ans, la période de maintien en conditions opérationnelles ne doit pas être inférieure à cinq ans ».
Pour déterminer la période de maintien en conditions opérationnelles, les fabricants doivent tenir compte de la durée d’utilisation prévue du produit, des attentes des utilisateurs, de la nature du produit, de sa finalité et de la période de maintien en conditions opérationnelles des produits similaires présents sur le marché.
La justification de l’établissement de la période de maintien en conditions opérationnelles doit être incluse dans la documentation des spécifications techniques, et la période de maintien en conditions opérationnelles doit être indiquée au moment de la distribution du produit.
Selon le compromis actuel, chaque mise à jour de sécurité doit rester disponible pendant au moins 10 ans. De même, la documentation doit rester disponible pendant 10 ans ou pendant la période de maintien en conditions opérationnelles du produit, la durée la plus longue étant retenue.
[Édité par Anne-Sophie Gayet et Théophane Hartmann]