Le traitement des logiciels open source par le Cyber Resilience Act (reglement (UE) 2024/2847) a constitue l’un des points les plus debattus du processus legislatif. L’ecosysteme du logiciel libre, qui represente selon la Commission europeenne entre 65 % et 95 % des composants presents dans les produits numeriques commerciaux, ne pouvait evidemment pas etre soumis aux memes regles que les editeurs commerciaux. Le legislateur europeen a donc du trouver un equilibre delicat entre la protection des utilisateurs et la preservation de l’innovation collaborative.

Le resultat est un dispositif a trois niveaux : une exemption de principe pour les projets non-commerciaux, un statut intermediaire pour les “intendants de logiciels libres” (open source software stewards), et l’application integrale du reglement lorsque le logiciel open source est integre 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 pose un principe clair : les logiciels libres et open source developpes ou fournis en dehors du cadre d’une activite commerciale ne sont pas soumis aux obligations du reglement. Le considerant 18 precise que la simple mise a disposition d’un logiciel open source ne constitue pas, en soi, une activite commerciale.

Cette exemption protege le developpeur individuel qui publie du code sur GitHub, le chercheur qui diffuse un outil de recherche, ou le benevole qui contribue a un projet communautaire. Sans cette exclusion, l’ecosysteme open source aurait ete paralyse par des obligations de conformite disproportionnees.

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

La notion d’activite commerciale est le pivot de tout le dispositif. Le CRA ne definit pas cette notion par reference au prix de vente – un logiciel gratuit peut relever d’une activite commerciale. Le considerant 18 identifie plusieurs indices determinants :

• la fourniture du logiciel dans le cadre d’une relation commerciale, meme si le logiciel lui-meme est gratuit (par exemple, un logiciel open source diffuse gratuitement mais adosse a 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 publicite ou la monetisation des donnees ;
• la sollicitation reguliere de dons dans un contexte depassant le simple financement des couts de developpement, lorsqu’elle s’apparente a une strategie commerciale.

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

• le developpement collaboratif par des benevoles ;
• la publication de code sous licence open source sans monetisation ;
• la reception de dons occasionnels destines a couvrir les frais de fonctionnement ;
• le financement par des subventions de recherche ou des organismes publics.

La frontiere est parfois subtile. Le CRA adopte une approche pragmatique fondee sur un faisceau d’indices plutot que sur un critere unique. En pratique, c’est l’intention commerciale globale qui determine si le logiciel entre dans le champ du reglement.

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

A. Definition et perimetre

Le CRA cree une categorie juridique inedite en droit europeen : l’“intendant de logiciel libre” (open source software steward), defini a l’article 3, point 14. Il s’agit de toute personne morale, autre qu’un fabricant, qui a pour objectif de soutenir de maniere systematique et durable le developpement de produits comportant des elements numeriques qualifies de logiciels libres et open source, destines a des activites commerciales.

En clair, cette definition vise les fondations et organisations qui encadrent des projets open source largement utilises dans l’industrie : la Linux Foundation, la fondation Apache, la fondation Eclipse, la fondation Python, mais aussi potentiellement des structures plus petites qui jouent un role similaire a une echelle plus modeste.

Le steward n’est pas un fabricant. Il ne met pas lui-meme le logiciel sur le marche au sens du CRA. Mais il joue un role structurant dans un ecosysteme dont dependent des millions de produits commerciaux. Le legislateur a juge logique de lui confier des responsabilites proportionnees a ce role.

B. Les obligations des stewards

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

1. L’adoption d’une politique de cybersecurite documentee, visant a favoriser le developpement securise du logiciel, a gerer efficacement les vulnerabilites et a promouvoir le partage d’informations au sein de la communaute.

2. La cooperation avec les autorites de surveillance du marche, en facilitant notamment l’acces a la documentation technique et en participant aux procedures de rappel ou de retrait lorsqu’un risque est identifie.

3. La gestion des vulnerabilites, incluant la mise en place de canaux de signalement, le traitement diligent des rapports de vulnerabilite et la coordination de la divulgation.

4. Le signalement des vulnerabilites activement exploitees aux autorites competentes (CSIRT designe et ENISA), dans les memes conditions que les fabricants – soit une notification initiale dans les 24 heures et une notification complete dans les 72 heures.

En revanche, les stewards ne sont pas tenus de realiser une evaluation de conformite, d’apposer le marquage CE, de produire une documentation technique complete au sens de l’annexe VII, ni de fournir une declaration de conformite. Ils ne sont pas non plus soumis aux sanctions administratives applicables aux fabricants (voir notre article sur les sanctions du CRA), mais a un regime d’amendes specifique, plafonne a 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 securite. En pratique, nombre d’entre elles disposent deja de programmes de gestion des vulnerabilites (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 difficulte portera davantage sur les structures plus petites qui maintiennent des projets critiques sans avoir les moyens organisationnels d’une grande fondation. Le CRA ne prevoit pas de seuil de taille pour l’application du statut de steward. Toute organisation qui remplit les criteres de la definition est concernee, quelle que soit sa taille.

III. L’open source integre dans un produit commercial : l’application integrale du CRA

A. Le principe de responsabilite du fabricant

Lorsqu’un logiciel open source est integre dans un produit commercial, l’exemption tombe. Le fabricant du produit final assume l’integralite des obligations du CRA, y compris pour les composants open source qu’il integre. Le considerant 19 est explicite : le fabricant qui integre un composant open source dans son produit doit s’assurer que ce composant respecte les exigences essentielles du reglement.

Cela signifie concretement que le fabricant doit :

• evaluer la securite des composants open source integres ;
• s’assurer de la disponibilite de correctifs de vulnerabilites pour ces composants ;
• documenter ces composants dans la documentation technique ;
• integrer ces composants dans son processus de gestion des vulnerabilites.

B. Les implications en matiere de SBOM

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

Pour les produits integrant de l’open source – c’est-a-dire la quasi-totalite des produits logiciels modernes --, cette obligation a des consequences majeures :

• Il faut maintenir un inventaire a jour de toutes les dependances open source, directes et transitives.
• Chaque composant doit etre suivi en matiere de vulnerabilites tout au long du cycle de vie du produit.
• Le SBOM doit etre mis a jour a chaque modification significative du produit.

En pratique, cela impose l’adoption d’outils automatises d’analyse de composition logicielle (SCA) et de generation 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 present.

1. Cartographier les dependances open source. Etablir un inventaire complet des composants open source utilises, avec leurs versions, licences et mainteneurs. Cette cartographie est le prealable indispensable a toute demarche de conformite.

2. Evaluer la maturite securite des projets critiques. Tous les projets open source n’offrent pas le meme niveau de suivi des vulnerabilites. Privilegier les composants maintenus activement, adosses a une fondation ou disposant d’un processus de securite documente.

3. Mettre en place une generation automatisee de SBOM. Integrer la generation de SBOM dans la chaine CI/CD. Les formats CycloneDX et SPDX sont les deux standards reconnus. L’automatisation est indispensable compte tenu du volume de dependances dans les projets modernes.

4. Organiser la veille vulnerabilite. Mettre en place un processus de surveillance continue des CVE affectant les composants integres. Des outils comme Dependabot, Snyk ou Trivy peuvent automatiser cette veille.

5. Contribuer aux projets critiques. Le CRA cree un interet economique direct a la securite des projets open source dont dependent vos produits. Contribuer financierement ou techniquement a ces projets n’est plus seulement une bonne pratique – c’est une mesure de gestion du risque reglementaire.

6. Anticiper le calendrier. Les obligations essentielles de cybersecurite s’appliquent a compter du 11 decembre 2027. Le signalement des vulnerabilites activement exploitees est obligatoire des le 11 septembre 2026. Le temps de mise en conformite est limite.

Conclusion

Le CRA instaure un cadre juridique nuance pour l’open source, qui tente de concilier deux imperatifs difficilement compatibles : la securite des produits mis sur le marche europeen et la preservation d’un ecosysteme collaboratif qui constitue le socle de l’industrie numerique. L’exemption pour les projets non-commerciaux et le statut intermediaire des stewards temoignent de cette volonte d’equilibre.

Mais il ne faut pas se meprendre sur la portee de ces exemptions. Pour les entreprises qui integrent de l’open source dans leurs produits – c’est-a-dire la quasi-totalite du marche --, le CRA impose une responsabilisation complete. La gratuite d’un composant ne dispense pas de sa securisation. C’est, en definitive, le message central du texte : celui qui met un produit sur le marche en assume la securite, composants open source inclus.