La plus grande partie d'un produit logiciel comportant des éléments numériques est du code que son fabricant n'a pas écrit : bibliothèques, frameworks, un système d'exploitation, une base de données, un service cloud. Le Cyber Resilience Act, règlement (UE) 2024/2847, ne rend pas le fabricant responsable de la conformité propre de ces composants. Il le rend responsable du produit dans son ensemble, et attache trois devoirs aux composants qu'il contient. Article 13(5) : faire preuve de diligence raisonnable en les intégrant. Article 13(6) : signaler les vulnérabilités que vous y trouvez à leur mainteneur, et partager les correctifs que vous écrivez. Annexe I, partie I, point 2(a), lu avec l'article 13(1) : mettre le produit sur le marché sans vulnérabilités exploitables connues. Le règlement énonce chacun en une phrase. Les orientations de la Commission du 27 juillet 2026, C(2026) 5252, sections 3.4, 7.3 et 9.2, disent ce que chacun exige, et cet article est ces sections, avec la FAQ de la Commission sur la mise en œuvre, version 1.4, section 5.4, là où elle ajoute quelque chose.

Qui est responsable d'un composant : seule la personne qui le met sur le marché

Le paragraphe 87 des orientations tranche la question que mainteneurs et intégrateurs posent tous deux : « L'applicabilité du CRA à un composant FOSS donné dépend uniquement de la question de savoir si la personne physique ou morale qui le publie le met sur le marché. » Intégrer un composant dans un produit monétisé « n'a aucune incidence sur le statut de ce composant FOSS », et le paragraphe 86 ajoute que les fabricants « ne deviennent pas responsables de la conformité individuelle de ces composants au CRA, même lorsqu'ils contribuent du code source à leur maintenance ». Quand un projet est mis sur le marché est une question pour son éditeur. Ce que l'intégrateur doit figure au paragraphe 88 : la conformité « de leurs propres produits comportant des éléments numériques », la diligence raisonnable de l'article 13(5) « envers les composants FOSS qu'ils intègrent », et les signalements et correctifs de l'article 13(6).

La diligence raisonnable, article 13(5) : décider ce dont vous avez besoin du composant, puis le vérifier

La section 7.3 trace la ligne entre l'évaluation des risques et la diligence raisonnable. L'évaluation des risques de l'article 13(2) couvre le produit et les risques qui l'atteignent de l'extérieur, « tels que les réseaux externes, les facteurs environnementaux ou d'autres aspects externes », et pour ceux-là « le CRA n'exige pas des fabricants qu'ils contrôlent ou gouvernent l'environnement externe », seulement « qu'ils identifient ces risques et les atténuent par la conception et le développement du produit » (paragraphe 168). L'exemple du paragraphe 169 est un back-end qui ne fait pas partie du produit mais pourrait servir à lui envoyer des commandes malveillantes : la réponse est au niveau du produit, « authentification cryptographique des commandes à distance, vérification de l'intégrité des changements de configuration ou génération de journaux de sécurité », et le règlement « n'impose pas d'obligations quant à la manière dont l'infrastructure back-end est organisée, dotée en personnel ou exploitée ».

La diligence raisonnable est l'autre devoir, et elle « concerne les éléments qui font partie du produit comportant des éléments numériques lui-même, en particulier les composants logiciels ou matériels intégrés fournis par un tiers » (paragraphe 170). Son contenu tient en une phrase du même paragraphe : elle « ne peut être réalisée qu'en déterminant ce que le produit comportant des éléments numériques exige de ses composants pour atteindre ses objectifs de cybersécurité, et en vérifiant, selon une approche fondée sur les risques, que ces composants répondent aux besoins du produit ». Le paragraphe 171 le rend concret : si le produit « s'appuie sur des fonctions cryptographiques, des mécanismes de mise à jour ou des communications sécurisées fournis par un composant, le fabricant doit, dans le cadre de sa diligence raisonnable, identifier ces besoins et vérifier que le composant y satisfait ». La preuve « peut consister en une documentation obtenue du fabricant du composant, telle que des spécifications techniques, une documentation de sécurité ou une documentation de conformité ou d'assurance pertinente », et « le cas échéant, le fabricant peut également effectuer des tests ».

Deux conséquences pour une liste de dépendances. D'abord, la diligence raisonnable est proportionnée et spécifique : elle demande ce que chaque composant fait pour la sécurité du produit et vérifie cela, pas tout sur chaque paquet. Une bibliothèque de journalisation et une bibliothèque TLS n'ont pas le même dossier. Ensuite, la vérification a lieu « lors de l'intégration » (paragraphe 172), et les composants sont traités « comme des composants fournis de l'extérieur dont les propriétés sont vérifiées par la diligence raisonnable », pas reconçus. Paragraphe 173 : « Lorsque le fabricant développe lui-même des fonctionnalités, il doit mettre directement en œuvre les exigences essentielles. Lorsque le fabricant intègre des composants développés par d'autres, il doit s'assurer, par la diligence raisonnable, que ces composants peuvent être utilisés d'une manière qui permette au produit comportant des éléments numériques dans son ensemble d'être conforme. »

Signaler en amont et partager les correctifs, article 13(6) : quatre limites que fixent les orientations

L'article 13(6) exige d'un fabricant qui identifie une vulnérabilité dans un composant intégré qu'il la signale « à la personne ou à l'entité qui fabrique ou maintient le composant », et qu'il partage tout correctif qu'il développe. La section 9.2.1 borne le devoir de quatre façons.

Seulement la version que vous intégrez, par le canal du mainteneur, et pas deux fois. Paragraphe 223 : les fabricants « ne sont tenus de signaler en amont qu'en ce qui concerne la version du composant qu'ils intègrent » ; lorsque le mainteneur a « des politiques de sécurité, des processus de divulgation coordonnée des vulnérabilités ou des canaux désignés », le signalement passe par eux ; et « les fabricants ne sont pas tenus de signaler en amont lorsqu'ils peuvent confirmer que la personne ou l'entité qui fabrique ou maintient un composant a connaissance de l'existence d'une vulnérabilité ». Les orientations demandent aux fabricants de consulter « les bases de données de vulnérabilités accessibles au public, les avis de sécurité propres au projet ou les systèmes de suivi établis avant de signaler en amont », pour épargner aux mainteneurs les doublons.

Seulement les vulnérabilités du composant, pas de votre intégration. Paragraphe 224 : le devoir couvre « les vulnérabilités qui existent dans le composant intégré lui-même, et non celles qui résultent de l'intégration entre le composant et d'autres codes développés par le fabricant ». Lorsque l'intégration révèle un comportement du composant qui n'était pas apparent isolément, en informer le mainteneur est encouragé, pas exigé.

Pas lorsqu'il n'y a pas de mainteneur. Paragraphe 225 : aucun signalement en amont n'est dû « lorsque le composant n'a plus de mainteneur, ou lorsque le fabricant ne dépend plus du mainteneur d'origine pour les nouvelles versions ou les correctifs de sécurité » ; informer les utilisateurs du composant par « les mécanismes communautaires existants (tels que les listes de diffusion ou les tickets) ou par des registres publics de vulnérabilités » est encouragé à la place.

Partager le correctif ; ne pas avoir à le faire fusionner. Paragraphes 226 à 229 : un correctif que vous développez pour une vulnérabilité d'un composant doit être partagé en amont, « le cas échéant, dans un format lisible par machine » et, pour un composant open source, « d'une manière compatible avec la licence de ce composant ». Mais les fabricants « ne sont pas tenus par le CRA de veiller à ce que leurs correctifs de sécurité soient nécessairement acceptés » ni « intégrés dans le dépôt de code du composant », ne sont pas tenus d'accepter en retour le correctif du mainteneur, et lorsqu'ils atténuent la vulnérabilité en modifiant autre chose dans leur propre système, « le CRA n'exige pas du fabricant qu'il partage en amont la modification d'une autre partie du système ».

Quand la vulnérabilité d'un composant est à vous de notifier aux autorités

La notification obligatoire de l'article 14 est un devoir distinct du signalement en amont, et les deux se confondent facilement. Le paragraphe 218 des orientations et la FAQ 5.4 tracent la ligne : un fabricant notifie une vulnérabilité activement exploitée « contenue dans son produit » ; lorsque la vulnérabilité d'un composant tiers « ne peut pas être exploitée dans son produit comportant des éléments numériques (par exemple parce que le code vulnérable n'est pas accessible) » ou « n'a pas été exploitée dans son produit », elle « n'est pas soumise à la notification obligatoire pour ce fabricant ». La FAQ ajoute que le fabricant du composant la notifie aussi, « si ce composant a été mis sur le marché », et que l'intégrateur « peut toujours notifier cette vulnérabilité sur une base volontaire, conformément à l'article 15 ». Une CVE listée dans une dépendance déclenche donc deux choses : l'évaluation d'accessibilité qui décide si l'horloge de 24 heures a démarré, et, si vous avez trouvé quelque chose que le mainteneur ignore, le signalement de l'article 13(6).

Les vulnérabilités exploitables connues au moment où vous livrez

La première exigence essentielle de l'annexe I, partie I, point 2(a), est de mettre le produit à disposition « sans vulnérabilités exploitables connues », et la section 9.2.2 répond aux deux mots que le règlement laisse ouverts. « Exploitable » est l'article 3(41) : « une vulnérabilité qui est susceptible d'être effectivement utilisée par un adversaire dans des conditions opérationnelles pratiques », que le paragraphe 231 oppose aux vulnérabilités exploitables « uniquement dans des conditions théoriques (par exemple en laboratoire ou en simulation) ». « Connue » relève des paragraphes 233 et 234, et c'est large : une vulnérabilité « devrait être considérée comme connue lorsqu'elle est répertoriée dans des bases de données de vulnérabilités accessibles au public pertinentes, telles que la base de données européenne des vulnérabilités » ou « d'autres bases de données de vulnérabilités de premier plan » ; lorsque le fabricant « en a été informé par des informations non publiques, par exemple par une divulgation coordonnée d'un chercheur en sécurité ou par ses propres tests et analyses internes, y compris, par exemple, en recourant à des services fondés sur l'IA » ; et « lorsqu'elle a fait l'objet d'une couverture publique et importante dans des médias fiables ».

Le paragraphe 235 garde la mesure : un signalement « ne signifie pas, en soi, qu'elle est exploitable en pratique ou applicable au produit concerné », le fabricant « devra enquêter et confirmer la véracité de ces informations et leur applicabilité », et « un délai limité peut s'écouler entre le premier signalement de la vulnérabilité et sa confirmation ». Les paragraphes 236 et 237 traitent de la version prévue le lendemain quand une nouvelle CVE tombe sur une dépendance : l'obligation « s'applique au moment de la mise sur le marché », c'est « une obligation fondée sur les risques », et le fabricant décide sur la base de « la gravité, l'exploitabilité et l'impact potentiel de la vulnérabilité » si le produit peut être mis sur le marché ou si la vulnérabilité doit être corrigée d'abord, et « peut aussi tenir compte des risques d'un report de la sortie du produit », par exemple lorsque la version corrige d'autres vulnérabilités exploitables. Une fois sur le marché, les obligations de gestion de l'annexe I, partie II, s'appliquent de toute façon.

Variantes et familles de produits

Une courte section qui épargne le plus de travail. Section 7.4 : lorsque des produits « partagent la même architecture, la même conception pertinente pour la sécurité et la même destination, et sont exposés aux mêmes risques de cybersécurité », le fabricant « peut s'appuyer sur (i) une seule évaluation des risques de cybersécurité », « (ii) un seul ensemble de documentation technique ; et (iii) une seule procédure d'évaluation de la conformité », et délivrer « une seule déclaration UE de conformité » qui « identifie clairement les variantes de produit auxquelles elle s'applique » (paragraphe 175). Le paragraphe 176 donne le test : des différences de « couleur, de format, de taille de mémoire ou d'autres caractéristiques sans incidence sur la sécurité » ne scindent pas la famille ; des différences « d'interfaces de communication, de piles logicielles, de mécanismes de mise à jour ou de connectivité à distance » la scindent, et doivent se refléter dans les documents.

Ce qu'il faut conserver, par composant

L'enregistrement qui satisfait les trois devoirs tient dans la SBOM que vous produisez déjà pour l'annexe I, partie II, point 1, une ligne par composant :

  1. Le nom, la version intégrée, et le contact sécurité ou le canal de divulgation du mainteneur.
  2. Ce dont le produit a besoin de lui pour sa sécurité, au sens du paragraphe 171 : rien, ou la cryptographie, les mises à jour, l'authentification, le transport, et ainsi de suite.
  3. La preuve que vous détenez pour ce besoin et la date à laquelle vous l'avez obtenue : la documentation du mainteneur, un élément d'assurance, votre propre test.
  4. L'accessibilité des vulnérabilités connues du composant dans votre produit, et la date de la dernière vérification contre les bases que nomme le paragraphe 233.
  5. Les signalements en amont effectués et les correctifs partagés, avec les dates, ou la confirmation que le mainteneur savait déjà.

Ce tableau est le dossier de diligence raisonnable, l'entrée de l'évaluation d'accessibilité quand une CVE apparaît, et la partie de la documentation technique qu'une autorité lira en premier quand la question sera « saviez-vous ».

Sources

  • Règlement (UE) 2024/2847, article 3(41), article 13(1), (2), (5) et (6), article 14(1), article 15, annexe I partie I point 2(a) et partie II point 1, considérant 34.
  • Commission européenne, orientations de la Commission sur l'application du règlement (UE) 2024/2847, C(2026) 5252 final du 27 juillet 2026, annexe, section 3.4 (paragraphes 85 à 88), sections 7.3 et 7.4 (paragraphes 167 à 177), section 9.1 paragraphe 218, sections 9.2.1 et 9.2.2 (paragraphes 222 à 237).
  • Commission européenne, FAQ sur le Cyber Resilience Act, version 1.4 du 4 septembre 2026, section 5.4.

Ceci n'est pas un avis juridique. Les sections 7.3 et 9.2 font sept pages à elles deux et répondent à la question des dépendances plus précisément que la page de n'importe quel éditeur d'outils ; lisez-les avec votre fichier de verrouillage ouvert.