CRA et logiciels open source : exemptions et obligations

Le traitement des logiciels open source par le Cyber Résilience Act (règlement (UE) 2024/2847) a constitue l’un des points les plus debattus du processus législatif. L’écosystème du logiciel libre, qui représente selon la Commission européenne entre 65 % et 95 % des composants présents dans les produits numériques commerciaux, ne pouvait évidemment pas être soumis aux mêmes règles que les éditeurs commerciaux. Le législateur européen a donc du trouver un équilibre délicat entre la protection des utilisateurs et la préservation de l’innovation collaborative.

Le résultat est un dispositif à trois niveaux : une exemption de principe pour les projets non-commerciaux, un statut intermédiaire pour les “intendants de logiciels libres” (open source software stewards), et l’application intégrale du règlement lorsque le logiciel open source est intègre dans un produit commercial. Analysons chacun de ces niveaux.

I. L’exemption de principe : le logiciel open source non commercial

A. Le principe d’exclusion

L’article 3, point 48, du CRA posé un principe clair : les logiciels libres et open source développés ou fournis en dehors du cadre d’une activité commerciale ne sont pas soumis aux obligations du règlement. Le considérant 18 precise que la simple mise à disposition d’un logiciel open source ne constitue pas, en soi, une activité commerciale.

Cette exemption protège le développeur individuel qui publie du code sur GitHub, le chercheur qui diffusé un outil de recherché, ou le benevole qui contribue à un projet communautaire. Sans cette exclusion, l’écosystème open source aurait été paralyse par des obligations de conformité disproportionnées.

B. Ce que signifie “activité commerciale” au sens du CRA

La notion d’activité commerciale est le pivot de tout le dispositif. Le CRA ne définit pas cette notion par référence au prix de vente – un logiciel gratuit peut relever d’une activité commerciale. Le considérant 18 identifie plusieurs indices déterminants :

• la fourniture du logiciel dans le cadre d’une relation commerciale, même si le logiciel lui-même est gratuit (par exemple, un logiciel open source diffusé gratuitement mais adosse à des services de support payants) ;
• l’utilisation du logiciel comme composant d’un produit ou service commercial ;
• le fait de percevoir des revenus lies au logiciel, que ce soit par la vente directe, le support, la publicité ou la monétisation des données ;
• la sollicitation régulière de dons dans un contexte dépassant le simple financement des coûts de développement, lorsqu’elle s’apparente à une stratégie commerciale.

En revanche, ne constituent pas des indices d’activité commerciale :

• le développement collaboratif par des benevoles ;
• la publication de code sous licence open source sans monétisation ;
• la réception de dons occasionnels destinés a couvrir les frais de fonctionnement ;
• le financement par des subventions de recherché ou des organismes publics.

La frontiere est parfois subtile. Le CRA adopté une approche pragmatique fondée sur un faisceau d’indices plutôt que sur un critère unique. En pratique, c’est l’intention commerciale globale qui déterminé si le logiciel entre dans le champ du règlement.

II. Les “intendants de logiciels libres” : un statut sur mesure

A. Définition et périmètre

Le CRA créé une catégorie juridique inédite en droit européen : l’“intendant de logiciel libre” (open source software steward), défini à l’article 3, point 14. Il s’agit de toute personne morale, autre qu’un fabricant, qui a pour objectif de soutenir de manière systématique et durable le développement de produits comportant des éléments numériques qualifiés de logiciels libres et open source, destinés à des activités commerciales.

En clair, cette définition vise les fondations et organisations qui encadrent des projets open source largement utilisés dans l’industrie : la Linux Foundation, la fondation Apache, la fondation Eclipse, la fondation Python, mais aussi potentiellement des structurés plus petites qui jouent un rôle similaire à une échelle plus modeste.

Le steward n’est pas un fabricant. Il ne met pas lui-même le logiciel sur le marché au sens du CRA. Mais il joué un rôle structurant dans un écosystème dont dépendent des millions de produits commerciaux. Le législateur a jugé logique de lui confier des responsabilités proportionnées à ce rôle.

B. Les obligations des stewards

Les obligations imposées aux stewards sont sensiblement plus legeres que celles des fabricants, mais elles ne sont pas négligeables. L’article 24 du CRA impose aux intendants de logiciels libres :

1. L’adoption d’une politique de cybersécurité documentée, visant à favoriser le développement sécurisé du logiciel, a gérer efficacement les vulnérabilités et a promouvoir le partagé d’informations au sein de la communauté.

2. La coopération avec les autorités de surveillance du marché, en facilitant notamment l’accès à la documentation technique et en participant aux procédures de rappel ou de retrait lorsqu’un risque est identifié.

3. La gestion des vulnérabilités, incluant la mise en place de canaux de signalement, le traitement diligent des rapports de vulnérabilité et la coordination de la divulgation.

4. Le signalement des vulnérabilités activement exploitées aux autorités compétentes (CSIRT désigné et ENISA), dans les mêmes conditions que les fabricants – soit une notification initiale dans les 24 heures et une notification complète dans les 72 heures.

En revanche, les stewards ne sont pas tenus de réaliser une évaluation de conformité, d’apposer le marquage CE, de produire une documentation technique complète au sens de l’annexe VII, ni de fournir une déclaration de conformité. Ils ne sont pas non plus soumis aux sanctions administratives applicables aux fabricants (voir notre article sur les sanctions du CRA), mais à un régime d’amendes spécifique, plafonne à 2,5 millions d’euros ou 1 % du chiffre d’affaires mondial.

C. Impact concret sur les fondations

Pour les grandes fondations open source, le CRA implique une structuration plus formelle de leurs pratiques de sécurité. En pratique, nombre d’entre elles disposent déjà de programmes de gestion des vulnérabilités (la Linux Foundation avec le projet OpenSSF, Apache avec son Security Team, Eclipse avec son processus de signalement). Le CRA vient juridiquement formaliser ces pratiques existantes.

La difficulté portera davantage sur les structurés plus petites qui maintiennent des projets critiques sans avoir les moyens organisationnels d’une grande fondation. Le CRA ne prévoit pas de seuil de taille pour l’application du statut de steward. Toute organisation qui remplit les critères de la définition est concernée, quelle que soit sa taille.

III. L’open source intègre dans un produit commercial : l’application intégrale du CRA

A. Le principe de responsabilité du fabricant

Lorsqu’un logiciel open source est intègre dans un produit commercial, l’exemption tombe. Le fabricant du produit final assumé l’intégralité des obligations du CRA, y compris pour les composants open source qu’il intègre. Le considérant 19 est explicité : le fabricant qui intègre un composant open source dans son produit doit s’assurer que ce composant respecte les exigences essentielles du règlement.

Cela signifie concrètement que le fabricant doit :

• évaluer la sécurité des composants open source intégrés ;
• s’assurer de la disponibilité de correctifs de vulnérabilités pour ces composants ;
• documenter ces composants dans la documentation technique ;
• intégrer ces composants dans son processus de gestion des vulnérabilités.

B. Les implications en matière de SBOM

Le CRA exigé que chaque produit soit accompagné d’un Software Bill of Materials (SBOM) documentant l’ensemble des composants, y compris les dépendances open source. L’annexe I, partie II, point 1, impose au fabricant d’identifier et de documenter les composants et les vulnérabilités du produit, en incluant un SBOM couvrant au minimum les dépendances de premier niveau.

Pour les produits intégrant de l’open source – c’est-à-dire la quasi-totalité des produits logiciels modernes --, cette obligation à des conséquences majeures :

• Il faut maintenir un inventaire à jour de toutes les dépendances open source, directes et transitives.
• Chaque composant doit être suivi en matière de vulnérabilités tout au long du cycle de vie du produit.
• Le SBOM doit être mis à jour à chaque modification significative du produit.

En pratique, cela impose l’adoption d’outils automatisés d’analyse de composition logicielle (SCA) et de génération de SBOM aux formats standardises (CycloneDX, SPDX).

IV. Recommandations pratiques pour les entreprises

Pour les organisations qui utilisent des composants open source dans leurs produits – et elles sont majoritaires --, plusieurs actions s’imposent des a présent.

1. Cartographier les dépendances open source. Établir un inventaire complet des composants open source utilisés, avec leurs versions, licences et mainteneurs. Cette cartographie est le préalable indispensable à toute démarche de conformité.

2. Évaluer la maturité sécurité des projets critiques. Tous les projets open source n’offrent pas le même niveau de suivi des vulnérabilités. Privilégier les composants maintenus activement, adosses à une fondation ou disposant d’un processus de sécurité documenté.

3. Mettre en place une génération automatisée de SBOM. Intégrer la génération de SBOM dans la chaîne CI/CD. Les formats CycloneDX et SPDX sont les deux standards reconnus. L’automatisation est indispensable compte tenu du volume de dépendances dans les projets modernes.

4. Organiser la veille vulnérabilité. Mettre en place un processus de surveillance continue des CVE affectant les composants intégrés. Des outils comme Dependabot, Snyk ou Trivy peuvent automatiser cette veille.

5. Contribuer aux projets critiques. Le CRA créé un intérêt économique direct à la sécurité des projets open source dont dépendent vos produits. Contribuer financièrement ou techniquement à ces projets n’est plus seulement une bonne pratique – c’est une mesure de gestion du risque réglementaire.

6. Anticiper le calendrier. Les obligations essentielles de cybersécurité s’appliquent à compter du 11 décembre 2027. Le signalement des vulnérabilités activement exploitées est obligatoire dès le 11 septembre 2026. Le temps de mise en conformité est limité.

Conclusion

Le CRA instaure un cadre juridique nuancé pour l’open source, qui tente de concilier deux impératifs difficilement compatibles : la sécurité des produits mis sur le marché européen et la préservation d’un écosystème collaboratif qui constitue le socle de l’industrie numérique. L’exemption pour les projets non-commerciaux et le statut intermédiaire des stewards témoignent de cette volonté d’équilibre.

Mais il ne faut pas se méprendre sur la portée de ces exemptions. Pour les entreprises qui intègrent de l’open source dans leurs produits – c’est-à-dire la quasi-totalité du marché --, le CRA impose une responsabilisation complète. La gratuité d’un composant ne dispense pas de sa sécurisation. C’est, en définitive, le message central du texte : celui qui met un produit sur le marché en assumé la sécurité, composants open source inclus.