Barry O’Donovan : la CRA change de rôle selon le produit

Résumé

La CRA s’attache à la manière dont un produit précis est fourni et soutenu. Barry O’Donovan estime qu’une organisation peut assurer le rôle d’organisme responsable d’un logiciel libre (open-source software steward dans le texte de la CRA) pour une édition gratuite et celui de fabricant pour une version payante.
Le statut associatif ne tranche pas la question. Les opérateurs ont toujours besoin d’un inventaire par produit, d’un point de contact pour les vulnérabilités et d’un chemin clair vers les correctifs.

Un même projet peut publier du code gratuit et vendre une édition enrichie. La CRA peut traiter ces produits différemment. C’est la lecture pratique de Barry O’Donovan : le rôle suit le produit, pas la plaque de l’organisation.

O’Donovan, développeur principal d’IXP Manager chez INEX, a présenté cette distinction à RIPE 93 dans une intervention sur les chaînes logicielles. Sa question pour les opérateurs était concrète : lorsqu’un échange Internet ou un réseau dépend d’un logiciel libre, quel travail de sécurité peut-il attendre du projet qui le fournit ?

Les orientations actuelles de la Commission européenne séparent deux rôles. Le fabricant qui met un produit libre sur le marché relève des obligations applicables aux fabricants. Une personne morale qui ne met pas le produit sur le marché, mais soutient de façon systématique et durable un produit libre précis destiné à des activités commerciales et en assure la viabilité, peut relever du statut d’organisme responsable d’un logiciel libre. Ce rôle impose une politique de cybersécurité, la gestion des vulnérabilités et une coopération avec les autorités de surveillance du marché.

O’Donovan a pris l’exemple d’un projet qui distribue gratuitement son édition libre, puis vend une édition enrichie. Selon son analyse, l’organisation peut assurer ce rôle pour la première et celui de fabricant pour la seconde. La Commission parle elle aussi de produits précis et de leur mode de fourniture. C’est une base plus utile qu’une étiquette CRA unique collée à une fondation, une entreprise ou une équipe de développement.

La loi freine les raccourcis. Un financement d’entreprise, des contributions externes ou des versions régulières ne suffisent pas, à eux seuls, à transformer un logiciel libre en activité commerciale. Le règlement prévoit aussi que le développement d’un logiciel libre par une organisation sans but lucratif n’est pas commercial si ses revenus nets sont consacrés à ses objectifs non lucratifs. Le prix, la responsabilité sur le produit, le soutien durable et l’usage commercial prévu doivent être examinés ensemble.

O’Donovan a cité IXP Manager. Il a expliqué qu’INEX considère le projet comme relevant de ce statut et avait publié des politiques de développement sécurisé et de divulgation des vulnérabilités après des demandes d’autres échanges. Il a aussi rappelé qu’INEX est une association sans but lucratif qui facture des ports de peering. C’est son interprétation opérationnelle, pas une décision de l’autorité sur IXP Manager. Le texte vise toujours le produit et le rôle réel de l’organisation.

Pour les opérateurs soumis à NIS2, les obligations de chaîne d’approvisionnement restent à leur charge. L’article 21 traite de la sécurité des fournisseurs et de la maintenance, y compris le traitement et la divulgation des vulnérabilités. O’Donovan recommande un inventaire logiciel, le suivi des failles et une politique de correctifs appliqués à temps.

Pendant les questions, il a prévu des cas simples et une zone grise qui finirait devant les tribunaux. Pour chaque logiciel utilisé, l’opérateur doit donc savoir qui contrôle les versions, qui reçoit les signalements, qui peut publier un correctif et quelle édition est fournie. Si le modèle commercial du produit évolue, son rôle juridique peut évoluer avec lui. Un inventaire limité au nom du fournisseur ne verra pas ce changement.