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
- La CRA, le FedRAMP, la norme NIS 2 et la norme PCI DSS posent les deux mêmes questions concernant vos composants open source : ce que vous distribuez, et ce qui se passe lorsqu'une vulnérabilité est détectée.
- Ces normes diffèrent quant au délai de référence (la norme PCI DSS prend en compte la date de publication du correctif, FedRAMP celle de l'évaluation, tandis que la CRA et la norme NIS 2 ne fixent pas de délai spécifique), quant à l'identité de la personne chargée d'examiner le dossier, et quant à la durée de conservation de celui-ci (seule la CRA précise une durée : au moins 10 ans).
- Aucune d'entre elles n'indique comment déterminer l'origine d'un composant, ni qui se chargera de fournir les correctifs une fois que ses responsables de maintenance auront cessé leurs activités.
- SecureChain répond à ces deux exigences : les paquets sont contrôlés, recompilés à partir du code source, mis à jour dans le cadre d'un SLA, puis livrés avec une traçabilité, une SBOM et des déclarations VEX.
La loi sur la cyber-résilience (CRA), le programme fédéral de gestion des risques et des autorisations (FedRAMP), la norme NIS 2 et la norme de sécurité des données du secteur des cartes de paiement (PCI DSS) vont bien au-delà de la simple preuve de conformité de la chaîne d’approvisionnement logicielle ; chacune soulève des questions pouvant porter sur les bibliothèques open source intégrées à votre produit. L'une de ces exigences est déjà assortie d'une date butoir : la norme PCI DSS impose la mise en place d'un inventaire des composants tiers à compter du 31 mars 2025.
Prenons l’exemple d’une entreprise hypothétique qui vend ses produits dans l’UE, fournit une entité relevant de la directive NIS 2, exploite un service cloud fédéral et traite des données de titulaires de cartes. Un progiciel open source pourrait susciter des questions de la part d’une autorité de surveillance du marché, du client NIS 2, d’une agence fédérale et d’un évaluateur de systèmes de paiement. D’où provient-il, et qui se chargera de le mettre à jour lorsque ses responsables de maintenance cesseront leurs activités ?
Ces quatre documents présentent des recoupements au niveau du contenu, mais diffèrent quant à savoir qui affiche quoi, à qui et pendant combien de temps. Le registre mentionné dans le titre est SecureChain de TuxCare, qui met à disposition des paquets open source via un dépôt sélectionné avec soin.
À qui s'adresse chaque document ?
Chaque document utilise son propre terme pour désigner la partie à laquelle il s’adresse, et ces termes ne sont pas interchangeables. La CRA s’adresse au fabricant, que l’article 3(13) définit comme une personne qui développe ou fabrique des produits comportant des éléments numériques, ou qui les fait fabriquer, et qui les commercialise sous son propre nom ou sa propre marque. Le « Playbook » de FedRAMP attribue la responsabilité principale des contrôles de sécurité au fournisseur de services cloud, et les règles de 2026 mentionnent le terme « fournisseur ». Le « Playbook » décrit le processus de la révision 5 ; FedRAMP l’héberge sur son site historique à titre de référence pendant la transition vers les règles de 2026. La norme NIS 2 s’applique aux entités essentielles et importantes, que les articles 2 et 3 définissent principalement en fonction de leur secteur d’activité et de leur taille. La norme PCI DSS s’applique aux entités qui stockent, traitent ou transmettent des données de titulaires de cartes, ou qui sont susceptibles d’affecter la sécurité de ces données. Cela inclut les prestataires de services, c’est-à-dire les entités autres que les marques de paiement qui traitent, stockent ou transmettent des données de titulaires de cartes pour le compte d’une autre entité, ou qui fournissent des services susceptibles d’affecter la sécurité de l’environnement des données des titulaires de cartes.
| Document | Nature juridique | Intitulé : | Situation au 28 octobre 2026 | Base |
|---|---|---|---|---|
| CRA, règlement (UE) n° 2024/2847 | Règlement, dont toutes les dispositions sont contraignantes et directement applicables | Fabricant (art. 3, paragraphe 13) | Entrée en vigueur le 11 décembre 2027. L'article 14 entre en vigueur le 11 septembre 2026. | Texte de reliure |
| Guide de surveillance continue FedRAMP v1.0 (17 novembre 2025) et Règles consolidées pour 2026 | Guide du programme (Playbook) et règlement du programme | Fournisseur de services cloud (Playbook), fournisseur (règles de 2026) | Ensembles de règles relatifs à la détection et à la réponse aux vulnérabilités (VDR) et à l'évaluation et au signalement des vulnérabilités (VER) : certification initiale et renouvellement à partir du 7 décembre 2026. Le délai de grâce prend fin le 7 mars 2027. | Guide pratique (Guide d'utilisation). Les règles marquées d'un astérisque sont obligatoires. |
| NIS 2, directive (UE) 2022/2555 | Directive, transposée dans le droit national de chaque État membre | Entités essentielles et importantes (articles 2 et 3) | Les États membres devaient adopter leurs mesures avant le 17 octobre 2024 ; celles-ci s'appliquent à compter du 18 octobre 2024 (art. 41, paragraphe 1). | Caractère contraignant pour les États membres |
| PCI DSS v4.0.1 (juin 2024) | Norme du secteur | Entités qui stockent, traitent ou transmettent des données relatives aux titulaires de cartes (section 2) | Version 4.0.1, juin 2024. L'exigence 6.3.2 est applicable depuis le 31 mars 2025. | Norme du secteur |
Une entreprise peut occuper plusieurs de ces rôles à la fois, par exemple celui de fabricant au titre de la CRA et celui de fournisseur de services cloud au titre du FedRAMP ; c’est donc son rôle qui détermine les questions du document qui s’appliquent à elle. Les éléments à présenter comme preuve de la conformité de la chaîne d’approvisionnement logicielle portent un nom différent dans chaque document. La CRA exige une documentation technique ; le « Playbook » de FedRAMP requiert des livrables et des pièces justificatives ; la norme NIS 2 exige des preuves de mise en œuvre ; et la norme PCI DSS exige qu’un évaluateur examine la documentation.
Remarque : la norme PCI DSS v4.0.1 laisse aux marques de paiement, aux acquéreurs et aux autres organismes chargés de gérer les programmes de conformité le soin de déterminer qui doit se conformer à la norme ou en valider la conformité (section 2).
Ce que chacun se demande au sujet des composants tiers
Le contenu de votre logiciel est désigné sous un nom différent dans chaque document. L'administration fiscale canadienne (CRA) nomme explicitement les composants open source. La norme NIS 2 fait référence aux fournisseurs directs et aux prestataires de services. Le guide FedRAMP, qui ne mentionne ni l'open source ni les nomenclatures logicielles, traite de l'inventaire et des vulnérabilités, tandis que la norme PCI DSS identifie les composants tiers présents dans les logiciels sur mesure et personnalisés.
| Document (nature) | Ce qu'il demande concernant les composants | Ce que vous montrez, et à qui | Taux de rétention déclaré | Base |
|---|---|---|---|---|
| CRA (réglementation) | Effectuer une vérification préalable des composants tiers (art. 13, paragraphe 5). Signaler les vulnérabilités des composants au responsable de la maintenance et y remédier (art. 13, paragraphe 6). Identifier et documenter les composants, à l'aide d'une nomenclature logicielle couvrant au moins les dépendances de premier niveau (annexe I, partie II, point 1). | Documentation technique (annexe VII), tenue à la disposition des autorités de surveillance du marché (art. 13, paragraphe 13). Liste des composants logiciels, sur demande motivée de l'autorité (annexe VII, point 8). | Documentation technique : au moins 10 ans à compter de la mise sur le marché du produit, ou pendant toute la durée du support si celle-ci est plus longue (art. 13, paragraphe 13) | Texte de reliure |
| FedRAMP (orientations et règles du programme) | Inventaire au moins une fois par mois (Guide pratique, section 2). Chaque vulnérabilité distincte fait l'objet d'un plan d'action et d'étapes clés (POA&M) qui lui est propre (section 3). La surveillance de la chaîne d'approvisionnement figure parmi les techniques de détection (VDR-CSO-DET). | Transmission mensuelle des rapports POA&M et de l'inventaire vers le référentiel sécurisé pour examen par l'agence (Playbook). Rapport mensuel sur les activités liées aux vulnérabilités à l'intention de toutes les parties concernées (VER-TFR-MHR). | Aucune mention n'est faite dans le « Playbook » ni dans le règlement VER. | Guide pratique (manuel). Les règles marquées d'un astérisque sont obligatoires. |
| NIS 2 (directive) | Sécurité de la chaîne d'approvisionnement, y compris les relations avec les fournisseurs directs (art. 21, paragraphe 2, point d)). Gestion et divulgation des vulnérabilités (art. 21, paragraphe 2, point e)). Évaluer les vulnérabilités, la qualité des produits et les pratiques en matière de cybersécurité de chaque fournisseur direct, y compris les procédures de développement sécurisées (art. 21, paragraphe 3). | Sur demande, présentation à l'autorité compétente de la preuve de la mise en œuvre des politiques de cybersécurité (art. 32, paragraphe 2, point g), pour les entités essentielles ; art. 33, paragraphe 2, point f), pour les entités importantes). | Aucune disposition prévue aux articles 21, 32 ou 33 | Caractère contraignant pour les États membres |
| PCI DSS v4.0.1 (norme du secteur) | Inventaire des logiciels sur mesure et personnalisés, ainsi que de leurs composants tiers (6.3.2). Les correctifs relatifs aux vulnérabilités critiques sont installés dans un délai d'un mois à compter de leur publication (6.3.3). Inventaire des composants système concernés (12.5.1). | Documents et entretiens examinés par un évaluateur (6.3.2.a, 6.3.2.b). | Aucune mention dans les sections 6.3.2, 6.3.3 ou 12.5.1 | Norme du secteur |
Remarque : l'article 13, paragraphe 5, étend l'obligation de diligence raisonnable aux composants libres et open source, même lorsqu'ils n'ont pas été mis à disposition dans le cadre d'une activité commerciale.
Les points de convergence et de divergence concernant les preuves de conformité de la chaîne d'approvisionnement logicielle
Le chevauchement porte sur le contenu des deux questions. La première concerne les composants que vous livrez. L’ARC, le « Playbook » et la norme PCI DSS exigent chacun une forme d’inventaire. La directive NIS 2 mentionne la gestion des actifs parmi les mesures prévues à l’article 21, paragraphe 2, point i), et pose des questions sur les fournisseurs, tandis que l’article 21 ne prévoit aucune liste de composants. L’autre point concerne la procédure à suivre lorsqu’une vulnérabilité est détectée, et les quatre documents abordent cette question. En vertu de la CRA, la correction doit être effectuée sans délai (annexe I, partie II, point 2). La directive NIS 2 mentionne la gestion et la divulgation des vulnérabilités (article 21, paragraphe 2, point e)). La norme PCI DSS fixe un délai d’un mois à compter de la publication pour les correctifs relatifs aux vulnérabilités critiques (6.3.3), et les règles FedRAMP de 2026 attribuent le label de vulnérabilité acceptée à tout élément restant ouvert 192 jours après l’évaluation (VER-TFR-MAV).
Les différences commencent par les délais. La norme PCI DSS compte à partir de la publication d’un correctif, FedRAMP à partir de l’évaluation, tandis que la CRA et la norme NIS 2 ne précisent pas de délai dans les dispositions citées ici. Elles divergent également quant au moment et aux destinataires auxquels il convient de communiquer des informations. Une autorité de surveillance du marché dispose de la documentation technique CRA ; les agences examinent les livrables mensuels du FedRAMP ; une autorité compétente peut demander des preuves à une entité NIS 2 ; et un évaluateur PCI DSS vérifie la documentation de l’entité. Il ne faut pas partir du principe qu’un dossier établi en fonction de la date de référence et du lecteur d’un document donné correspondra à celui d’un autre.
Ce que les documents laissent à votre appréciation
Ces quatre documents posent la question tout en laissant une grande marge de manœuvre quant à la méthode à adopter. La CRA exige des fabricants qu’ils documentent les aspects liés à la cybersécurité du produit d’une manière proportionnée au risque (article 13, paragraphe 7), tandis que la directive NIS 2 préconise des mesures appropriées et proportionnées (article 21, paragraphe 1). La norme PCI DSS laisse le choix du moment d’application des autres correctifs applicables, ceux qui ne concernent pas des vulnérabilités critiques, à l’appréciation de l’entité elle-même (6.3.3), tandis que la règle de détection du programme FedRAMP préconise le recours à des techniques appropriées (VDR-CSO-DET).
Deux questions restent en suspens dans les dispositions citées jusqu’à présent. La première concerne l’origine d’un composant. L’article 13, paragraphe 5, de la CRA exige une diligence raisonnable afin que les composants tiers ne compromettent pas le produit, tandis que l’article 21, paragraphe 3, de la directive NIS 2 impose aux entités d’évaluer les procédures de développement sécurisées de leurs fournisseurs. Le considérant 85 de la directive NIS 2, qui n’a pas de caractère contraignant, décrit comment les attaquants compromettent les entités en exploitant les vulnérabilités de produits et services tiers. Aucun de ces articles n’explique comment vérifier qu’un composant provient bien de la source qu’il prétend provenir ou qu’il ne contient aucun code malveillant.
Le deuxième point concerne l’origine du correctif. La norme PCI DSS 6.3.3 prévoit un délai d’un mois à compter de la publication d’un correctif, ce qui suppose donc qu’un correctif ait été publié. La CRA attribue au fabricant l’obligation de fournir des mises à jour de sécurité (annexe I, partie II(2)), et l’article 13(8) maintient les vulnérabilités des composants d’un produit dans le champ d’application pendant toute la durée de la période de support prévue par la CRA. Dans le cadre du cycle de surveillance continue de la version 5 du programme FedRAMP, un problème pour lequel aucun correctif en amont n’est disponible reste inscrit sur le rapport mensuel POA&M en tant que dépendance vis-à-vis du fournisseur. Pour les prestataires comptant plusieurs agences parmi leurs clients, le guide opérationnel (Playbook) oriente la réunion collaborative mensuelle vers les éléments en retard et les dépendances vis-à-vis des fournisseurs (section 7). Aucune de ces dispositions ne précise d’où provient le correctif lui-même une fois que les responsables de la maintenance ont cessé de les publier.
Le rôle de SecureChain dans le domaine des logiciels libres
SecureChain, de TuxCare, analyse le code source des paquets open source à la recherche de logiciels malveillants cachés, puis les recompile dans un environnement isolé à partir de ce code analysé. Les paquets qui ne passent pas l'inspection sont bloqués avant d'atteindre l'environnement du client, tandis que les autres sont mis à disposition via un dépôt soigneusement sélectionné.
Chaque paquet est livré avec une traçabilité (un enregistrement signé décrivant son processus de construction, conforme au niveau 3 de la norme SLSA), une SBOM, des déclarations VEX, ainsi que les informations relatives à l'origine et au statut des corrections demandées dans les documents susmentionnés.
SecureChain corrige les composants actifs dans le cadre d'un accord de niveau de service. Pour les versions qui ne sont plus prises en charge en amont, le programme Endless Lifecycle Support (ELS) réintègre les correctifs relatifs aux vulnérabilités à risque critique, élevé, moyen et faible dans les versions utilisées, selon un calendrier défini. SecureChain couvre les bibliothèques open source en JavaScript, Python, Java, Go et PHP.
Si vous ne savez pas encore d'où provient un composant, ni qui assure sa maintenance une fois que le développement en amont a cessé, découvrez comment SecureChain for Open Source Software aborde ces deux aspects.
FAQ
Comment la CRA, le FedRAMP, la norme NIS 2 et la norme PCI DSS utilisent-ils le terme « preuve » ?
Ces quatre textes y font référence, dans des sens différents. L’annexe VII de la loi sur la cyber-résilience (Cyber Resilience Act) mentionne la présence d’une adresse de contact pour le signalement des vulnérabilités dans la documentation technique. Les articles 32 et 33 de la directive NIS 2 permettent aux autorités de demander des preuves de mise en œuvre. Le « Playbook » du Programme fédéral de gestion des risques et des autorisations (Federal Risk and Authorization Management Program) mentionne les éléments justificatifs, et la norme de sécurité des données de l'industrie des cartes de paiement (Payment Card Industry Data Security Standard) prévoit que les évaluateurs examinent la documentation et interrogent le personnel (6.3.2.a, 6.3.2.b).
Combien de temps faut-il conserver la documentation technique relative à la CRA ?
En vertu de la loi sur la cyber-résilience (CRA), article 13, paragraphe 13, les fabricants sont tenus de mettre la documentation technique à la disposition des autorités de surveillance du marché pendant au moins dix ans à compter de la mise sur le marché du produit, ou pendant la durée de l'assistance technique si celle-ci est plus longue. L'annexe VII énumère les éléments devant figurer dans cette documentation, y compris, le cas échéant, une nomenclature logicielle.
Quelles sont les amendes prévues par la CRA et le NIS 2 ?
L'article 64, paragraphe 2, de la loi sur la cyber-résilience prévoit des amendes pouvant aller jusqu'à 15 000 000 d'euros ou 2,5 % du chiffre d'affaires annuel mondial total de l'exercice financier précédent en cas de violation de l'annexe I et des articles 13 et 14. L’article 34 de la directive NIS 2 impose aux États membres de fixer des plafonds d’au moins 10 000 000 d’euros ou 2 % du chiffre d’affaires pour les entités essentielles, et de 7 000 000 d’euros ou 1,4 % du chiffre d’affaires pour les entités importantes. Dans tous les cas, c’est le montant le plus élevé qui s’applique.
Comment la norme NIS 2 s'applique-t-elle à un éditeur de logiciels ?
La directive NIS 2 impose ses obligations aux entités essentielles et importantes ; par conséquent, on accède généralement à un fournisseur par l’intermédiaire d’un client. L’article 21, paragraphe 2, point d), et l’article 21, paragraphe 3, exigent de l’entité qu’elle évalue les vulnérabilités de chaque fournisseur direct et qu’elle mette en place des procédures de développement sécurisées. Un fournisseur qui est lui-même une entité essentielle ou importante relève de plein droit de la directive, en vertu de la législation de l’État membre.
Dans quels cas la norme PCI DSS exige-t-elle un inventaire des composants tiers ?
L'exigence 6.3.2 de la norme PCI DSS (Payment Card Industry Data Security Standard) v4.0.1, une norme sectorielle, porte sur les composants tiers intégrés dans des logiciels sur mesure et personnalisés. Il s'agissait d'une bonne pratique jusqu'au 31 mars 2025 ; cette exigence deviendra obligatoire après cette date. La décision de savoir si une entité doit procéder à cette validation revient aux marques de paiement, aux acquéreurs et aux autres organisations qui gèrent des programmes de conformité.
