Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- L'article 13, paragraphe 5, de la loi sur la cyber-résilience (CRA) impose une obligation de diligence raisonnable concernant les composants tiers, y compris ceux issus de l'open source.
- Toute infraction à l'article 13 est passible d'amendes pouvant aller jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu.
- Le considérant 34, qui n'a pas de caractère contraignant, établit un lien entre la diligence raisonnable et le risque lié aux composants et énumère quatre mesures possibles, mais c'est à vous de choisir la méthode à adopter et de la documenter.
- Conformément aux recommandations de la Commission européenne, l’intégration d’un composant open source ne vous dégage pas de la responsabilité de sa conformité au CRA. La conformité de votre produit continue de s’étendre à ce composant, y compris la gestion de ses vulnérabilités pendant toute la durée de votre période de support, même après que le développeur en amont a cessé de le corriger.
- Les actions décrites au considérant 34 ne permettent pas de déterminer si un paquet a été compilé à partir de son code source publié ou s'il contient du code injecté ; c'est donc à vous, en fonction de votre propre évaluation des risques, de décider dans quelle mesure vous souhaitez vérifier ces deux aspects.
Si votre produit intègre des composants open source, la loi sur la cyber-résilience (CRA) vous impose de faire preuve de diligence raisonnable à leur égard à compter du 11 décembre 2027. Les recommandations non contraignantes de la Commission européenne précisent que les responsables de maintenance qui ne commercialisent pas leurs composants open source n’ont aucune obligation envers vous au titre de la CRA. L’article 13, paragraphe 5, étend votre obligation de diligence raisonnable même à ces composants ; ainsi, une bibliothèque dont le responsable de maintenance ne tire aucun profit financier est tout de même prise en compte.
Quel est le niveau de diligence raisonnable requis ? L’ARC laisse cette question ouverte, et le considérant 34 adapte ce niveau au risque présenté par le composant et énumère des exemples de mesures sans en exiger aucune en particulier. Aucune de ces mesures ne vérifie si le paquet sur lequel votre produit s’exécute a été compilé à partir du code source publié ou s’il contient du code qui n’a pas sa place dans celui-ci. La décision vous appartient, et tout manquement peut entraîner des amendes administratives (article 64, paragraphe 2).
Ce que prévoit la loi sur la cyber-résilience concernant les composants que vous n’avez pas développés
La loi européenne sur la cyber-résilience, le règlement (UE) 2024/2847, impose aux fabricants une obligation de diligence raisonnable. Un produit comportant des éléments numériques est un produit logiciel ou matériel, y compris les composants logiciels ou matériels mis sur le marché séparément (article 3, paragraphe 1). L’article 3, paragraphe 13, définit un fabricant comme une personne physique ou morale qui développe ou fabrique de tels produits, ou qui les fait concevoir, développer ou fabriquer, et qui les commercialise sous son nom ou sa marque. Cette définition s’applique que le produit soit vendu, monétisé ou offert gratuitement.
Un composant est un logiciel ou un matériel destiné à être intégré dans un système d'information électronique (article 3, paragraphe 6) ; par conséquent, une bibliothèque open source sur laquelle repose votre produit répondra généralement à cette définition. En vertu de l'article 2, paragraphe 1, la CRA s'applique aux produits mis à disposition sur le marché dont la destination ou l'utilisation raisonnablement prévisible comprend une connexion de données à un appareil ou à un réseau.
L’article 3, paragraphe 22, définit la notion de « mise à disposition sur le marché » comme la fourniture, à des fins de distribution ou d’utilisation sur le marché de l’UE, dans le cadre d’une activité commerciale, que ce soit à titre onéreux ou gratuit. La fourniture gratuite d’un produit peut tout de même revêtir un caractère commercial. En ce qui concerne les logiciels libres, ce qui importe, c’est de savoir si l’éditeur en tire un profit, par exemple en le facturant, en subordonnant l’accès aux versions ou aux mises à jour à un paiement, ou en l’utilisant pour vendre d’autres services (considérant 18 ; lignes directrices de la Commission, section 3.2). Une bibliothèque fournie par son responsable en dehors d’une activité commerciale n’est pas considérée comme un produit, mais elle reste néanmoins un composant de votre produit.
L'article 13, paragraphe 5, impose aux fabricants de faire preuve de diligence raisonnable lors de l'intégration de composants provenant de tiers, afin que ces composants ne compromettent pas la cybersécurité du produit. Il inclut expressément les composants libres et open source qui n'ont pas été mis à disposition sur le marché dans le cadre d'une activité commerciale. L'article 13 s'applique à compter du 11 décembre 2027 (article 71, paragraphe 2).
Toute infraction à l'article 13 est passible d'amendes administratives pouvant aller jusqu'à 15 000 000 d'euros ou, pour une « entreprise » (terme utilisé dans le jargon de l'UE pour désigner une société), jusqu'à 2,5 % de son chiffre d'affaires annuel mondial total pour l'exercice financier précédent, le montant le plus élevé étant retenu (article 64, paragraphe 2).
L'indemnisation des dommages causés par des produits défectueux relève d'un régime distinct, à savoir la directive (UE) 2024/2853, dite « directive sur la responsabilité du fait des produits ». Le considérant 31 précise que ce régime est complémentaire de la CRA et indique que l'absence de mises à jour de sécurité entraînant un préjudice pourrait engager la responsabilité du fabricant en vertu de cette directive.
Ce que la diligence raisonnable permet et ne permet pas de déterminer
La loi sur la cyber-résilience (CRA) impose aux fabricants de faire preuve de diligence raisonnable, et c’est dans le considérant 34, qui n’a pas de caractère contraignant, que le texte entre davantage dans les détails. Il précise que le niveau approprié dépend de la nature et de l’ampleur du risque de cybersécurité associé à un composant, et que la diligence raisonnable doit tenir compte d’une ou plusieurs des quatre mesures énumérées (tableau 1). La FAQ de la Commission sur la CRA, un document de questions-réponses distinct de ses lignes directrices, ajoute d’autres exemples.
Tableau 1. Mesures mentionnées par les sources en matière de diligence raisonnable concernant un composant
| Action | Source | Base |
|---|---|---|
| Le cas échéant, vérifiez que le fabricant du composant a démontré la conformité à la CRA, par exemple au moyen du marquage CE. | Considérant 34 | Récital (d'interprétation) |
| Vérifiez que le composant bénéficie de mises à jour de sécurité régulières, par exemple en consultant son historique des mises à jour | Considérant 34 | Récital (d'interprétation) |
| Vérifiez que le composant ne présente aucune vulnérabilité répertoriée dans la base de données européenne des vulnérabilités ou dans d'autres bases de données publiques sur les vulnérabilités. | Considérant 34 | Récital (d'interprétation) |
| Réaliser des tests de sécurité supplémentaires | Considérant 34 | Récital (d'interprétation) |
| Effectuer une analyse de la composition logicielle, identifier les composants hautement critiques, examiner la nomenclature logicielle (SBOM) de ces composants lorsqu'elle est disponible, vérifier leur durée de prise en charge, s'assurer que leur usage prévu correspond à celui indiqué par le fabricant, ou évaluer le niveau de sécurité de leur éditeur | FAQ de la Commission, réponse 4.4.2 (version 1.4, 4 septembre 2026) | FAQ sur la Commission (à titre indicatif) |
Remarque : la rubrique « FAQ » de la Commission précise que ses réponses n'ajoutent aucune exigence et que ses avis n'ont pas valeur de référence.
Le considérant 34 mentionne « une ou plusieurs », ce qui signifie qu’aucune mesure particulière n’est considérée comme obligatoire. Ni ce considérant, ni l’article 13, paragraphe 5, ne prescrivent de méthode, de niveau de détail ou de format d’enregistrement.
L’annexe VII énumère les éléments que doit contenir la documentation technique. Elle mentionne l’évaluation des risques, la description de la manière dont les composants logiciels s’intègrent dans le système global et les rapports d’essais, mais ne comporte pas de rubrique distincte consacrée à la diligence raisonnable relative aux composants. Cela ne signifie pas pour autant que la diligence raisonnable ne soit pas consignée. L’article 13, paragraphe 7, impose toujours aux fabricants de documenter systématiquement les aspects pertinents du produit en matière de cybersécurité, de manière proportionnée à sa nature et aux risques de cybersécurité qu’il présente.
Le niveau étant défini par le risque et la méthode laissée à votre appréciation, c’est votre propre raisonnement qui détermine le degré de diligence raisonnable à appliquer à chaque composant. Les orientations de la Commission (points 170 et 171) divisent cette obligation en deux étapes : utilisez l’évaluation des risques de votre produit pour identifier ce que le produit attend de chaque composant, puis vérifiez que le composant répond bien à ces exigences. Une note relative à cette vérification, rédigée au moment de l’intégration du composant, est plus fiable qu’une note reconstituée des années plus tard, car l’article 13, paragraphe 5, lie cette obligation à l’intégration.
Ce qui reste gravé dans votre mémoire et ce qui ne le reste pas
Les lignes directrices de la Commission du 27 juillet 2026 précisent que les fabricants qui intègrent des composants open source ne sont pas responsables de la conformité individuelle de ces composants à la CRA, même lorsqu’ils contribuent au code source dans le cadre de leur maintenance (point 86). Ils conservent toutefois leurs propres obligations concernant le produit, notamment l’obligation de diligence prévue à l’article 13, paragraphe 5, ainsi que l’obligation de signaler les vulnérabilités et de partager les correctifs prévue à l’article 13, paragraphe 6 (point 88).
Les gestionnaires et responsables de maintenance en amont ont des obligations en matière de CRA nettement moins contraignantes que celles des fabricants. L’article 3, paragraphe 14, définit un gestionnaire de logiciel libre comme une personne morale, autre qu’un fabricant, dont l’objet est de soutenir systématiquement et de manière durable le développement de produits libres et open source spécifiques destinés à des activités commerciales, et qui assure leur viabilité. L’article 24 prévoit un régime allégé pour les gestionnaires : une politique de cybersécurité documentée, une coopération avec les autorités de surveillance du marché et, dans des cas limités, certaines dispositions de l’article 14 relatives à la notification des vulnérabilités exploitées et des incidents (article 24, paragraphe 3). Les lignes directrices précisent que les responsables de la maintenance de composants qui n’ont pas été mis à disposition sur le marché n’ont aucune obligation envers les fabricants qui les intègrent (point 87).
Vos obligations ne se limitent pas à l’intégration. L’article 13, paragraphe 6, vous impose de signaler toute vulnérabilité que vous identifiez dans un composant à son fabricant ou à son responsable de la maintenance, afin qu’il y remédie, et de partager le code ou la documentation pertinente si vous avez développé un correctif. L’article 13, paragraphe 8, exige que les vulnérabilités du produit, y compris celles de ses composants, soient traitées efficacement pendant toute la durée de la période de support que vous avez définie. Cette période doit être d’au moins 5 ans, sauf si le produit est censé être utilisé pendant moins de 5 ans. En vertu de la CRA, ni les gestionnaires (article 24) ni les responsables de la maintenance des composants qui n’ont pas été mis sur le marché (point 87) ne sont tenus de vous garantir une période de support ; ainsi, une version d’un composant peut cesser de bénéficier de correctifs en amont alors que la période de support de votre produit s’étend encore sur plusieurs années.
Les actions répertoriées ne demandent pas comment un paquet a été compilé
Trois des quatre mesures énoncées au considérant 34 portent sur les informations publiques disponibles concernant un composant. Elles visent à déterminer si son fabricant a démontré sa conformité, s’il bénéficie de mises à jour de sécurité régulières et ce qu’en indiquent les bases de données sur les vulnérabilités. La quatrième mesure, à savoir les tests de sécurité supplémentaires, est la seule qui vous demande de tester vous-même le composant.
La fiche d’un composant décrit le comportement d’un projet, mais elle ne précise pas si le paquet qui sera finalement exécuté par votre produit a été compilé à partir du code source publié par le projet, ni s’il contient du code qui n’a pas sa place dans celui-ci. La provenance de la compilation et le code injecté n’apparaissent nulle part parmi les actions mentionnées au considérant 34 ni dans les exemples figurant dans la FAQ de la Commission. Or, ces deux éléments ont une incidence directe sur le fait qu’un composant compromette ou non la cybersécurité du produit, conséquence que l’article 13, paragraphe 5, vise précisément à prévenir.
L'article 13, paragraphe 5, ne prescrit pas de méthode particulière ; c'est donc à vous de décider comment vérifier la provenance et rechercher d'éventuels codes injectés. Vous pouvez notamment comparer un paquet à son code source et le passer au crible à la recherche de code malveillant avant qu'il n'entre dans votre environnement. Une SBOM répertorie les composants d'un produit, mais le simple fait de lister un paquet ne permet pas de vérifier comment il a été construit ni quel code il contient. Votre évaluation des risques devrait vous indiquer le niveau de vérification requis pour chaque composant.
Vérification des paquets avant leur installation dans votre environnement
SecureChain de TuxCare analyse le code source des paquets open source qu’il couvre à la recherche de logiciels malveillants connus, de modèles de code suspects et d’autres risques liés à la chaîne d’approvisionnement, puis recompose les paquets à partir de ce code source analysé au sein d’environnements de compilation renforcés et isolés. Les paquets qui ne passent pas l’analyse sont bloqués avant d’atteindre votre environnement. Chaque paquet est accompagné d’une SBOM, d’un document VEX et d’une traçabilité SLSA de niveau 3, c’est-à-dire un enregistrement de la source et de la compilation qui l’ont produit.
Pour les composants qui font encore l'objet d'une maintenance active, SecureChain fournit des correctifs sous forme de paquets recompilés dans le cadre d'un contrat de niveau de service, à mesure que de nouvelles vulnérabilités apparaissent. Une fois la maintenance en amont terminée, le service « Endless Lifecycle Support » de TuxCare continue de corriger les vulnérabilités de tous les niveaux de gravité, de « critique » à « faible », dans les versions spécifiques que vous utilisez.
Vous ne pouvez pas vérifier le contenu des paquets que vous envoyez ? Découvrez comment SecureChain les vérifie avant qu’ils ne soient intégrés à vos versions.
FAQ
Qui est concerné par la loi sur la cyber-résilience ?
La loi sur la cyber-résilience (CRA), qui constitue le règlement de l’UE relatif à la cybersécurité des produits, s’applique aux produits comportant des éléments numériques qui sont mis à disposition sur le marché de l’UE dans le cadre d’une activité commerciale et dont la destination ou l’utilisation raisonnablement prévisible implique une connexion de données à un appareil ou à un réseau (articles 2, paragraphe 1, et 3, paragraphe 22). Les obligations incombent principalement aux fabricants. Les importateurs, les distributeurs et les responsables de logiciels libres ont des obligations distinctes (articles 19, 20 et 24).
Quand les dispositions de la loi sur la cyber-résilience s'appliquent-elles ?
La loi sur la cyber-résilience (CRA) est entrée en vigueur le 10 décembre 2024. Le chapitre IV, relatif à la notification des organismes d'évaluation de la conformité, s'applique depuis le 11 juin 2026, et l'article 14, relatif aux déclarations des fabricants, depuis le 11 septembre 2026. Les autres dispositions s'appliquent à compter du 11 décembre 2027 (article 71, paragraphe 2).
La CRA remplace-t-elle les règles relatives à la responsabilité du fait des produits ?
Non. Le considérant 31 de la loi sur la cyber-résilience (CRA) qualifie la directive (UE) 2024/2853, dite « directive sur la responsabilité du fait des produits », de complémentaire. Cette directive régit l’indemnisation des dommages causés par des produits défectueux, tandis que la CRA définit les obligations des fabricants, assorties d’amendes administratives (article 64). L’article 65 applique les règles de l’Union européenne relatives aux actions collectives aux infractions qui portent atteinte ou sont susceptibles de porter atteinte aux intérêts collectifs des consommateurs.
Les fabricants peuvent-ils utiliser des logiciels libres provenant de responsables que l'Autorité des assurances (CRA) ne réglemente pas ?
Oui, à condition que le fabricant fasse preuve de la diligence requise pour s'assurer que ces composants ne compromettent pas la cybersécurité du produit. L'article 13, paragraphe 5, de la loi sur la cyber-résilience (CRA) couvre expressément les composants open source qui n'ont pas été mis à disposition sur le marché à des fins commerciales, et le considérant 34 précise que le niveau de sécurité dépend du risque présenté par le composant.
Les fabricants sont-ils tenus de signaler les vulnérabilités des composants au responsable de la maintenance ?
Oui, dès qu’il en identifie une. À compter du 11 décembre 2027, l’article 13, paragraphe 6, de la loi sur la cyber-résilience (CRA) impose au fabricant de signaler toute vulnérabilité présente dans un composant intégré, y compris s’il s’agit d’un composant open source, à celui qui le fabrique ou en assure la maintenance, et de la corriger. Si le fabricant met au point un correctif, il doit partager le code ou la documentation correspondante. Cette obligation est distincte de celle prévue à l’article 14 concernant la déclaration aux autorités, qui s’applique depuis le 11 septembre 2026.
