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 21 de la directive NIS 2 fait de la sécurité de la chaîne d'approvisionnement une mesure minimale et impose aux entités d'évaluer les vulnérabilités de chacun de leurs fournisseurs directs.
- L'ENISA, l'agence européenne chargée de la cybersécurité, précise dans ses lignes directrices non contraignantes relatives aux marchés publics hospitaliers que les responsables de projets open source ne peuvent pas être considérés comme des fournisseurs directs.
- Les composants open source ajoutés par les développeurs n'ont parfois pas de fournisseur à qui s'adresser ; c'est donc à votre équipe qu'il revient de les faire vérifier.
- Les organes de direction approuvent les mesures prévues à l'article 21 et peuvent être tenus pour responsables ; veillez donc à ce que ces mesures couvrent les logiciels libres ajoutés par les développeurs.
Un registre des fournisseurs établi à partir des contrats peut sembler exhaustif tout en omettant le code open source présent dans vos logiciels. La mesure de sécurité relative à la chaîne d'approvisionnement prévue par la deuxième directive sur la sécurité des réseaux et de l'information (NIS2) vise spécifiquement vos fournisseurs directs. Or, le code open source ajouté par vos propres développeurs peut ne pas avoir de fournisseur à qui envoyer un questionnaire.
Alors, qui considère-t-on comme votre fournisseur lorsque le code est open source? La réponse à cette question détermine les questions que vous pouvez poser à un fournisseur et les vérifications qui incombent à votre équipe.
Quelle que soit la réponse, le fait de s'approvisionner auprès d'un fournisseur ne vous décharge pas de vos obligations au titre de la directive NIS 2. La directive exige des organisations concernées qu'elles gèrent les risques liés aux fournisseurs par leurs propres moyens, et l'Agence de l'Union européenne chargée de la cybersécurité (ENISA) précise dans ses orientations techniques de mise en œuvre, qui n'ont pas de caractère contraignant, que l'externalisation d'un risque ne vous dégage pas de votre responsabilité à cet égard.
Ce que la mesure relative à la sécurité de la chaîne d'approvisionnement prévue par la directive NIS 2 attend de vous
Cette mesure s'applique aux entités essentielles et importantes, les deux catégories définies par la directive NIS2, en fonction du caractère critique d'un secteur ou d'un service et de la taille de l'organisation. Dans la pratique, cela concerne généralement les organisations de taille moyenne et les grandes organisations des secteurs répertoriés, ainsi que certaines plus petites ; toutes les entreprises ne sont donc pas concernées.
L'article 21, paragraphe 2, énumère dix mesures qu'une entité doit prendre au minimum. Celle visée au point d) concerne la sécurité de la chaîne d’approvisionnement. Elle englobe l’aspect sécuritaire des relations de chaque entité avec ses fournisseurs directs ou ses prestataires de services. L’article 21, paragraphe 3, précise ensuite les éléments à prendre en compte pour cette mesure : les vulnérabilités spécifiques à chaque fournisseur direct et prestataire de services ; la qualité globale des produits et les pratiques en matière de cybersécurité des fournisseurs, y compris leurs procédures de développement sécurisées ; et les résultats de toute évaluation des risques coordonnée au niveau de l’Union concernant les chaînes d’approvisionnement critiques.
Telles sont les exigences en matière de sécurité de la chaîne d’approvisionnement telles qu’énoncées dans la directive. Une directive s’imposant aux États membres plutôt qu’aux entreprises, ces règles s’appliquent aux entités par le biais de la législation nationale de chaque pays. L’article 21, paragraphe 1, exige également que les mesures soient adaptées et proportionnées aux risques, ce qui vous laisse une certaine marge de manœuvre dans leur conception.
Un considérant de la directive NIS 2 et plusieurs autres textes de l’UE font également référence aux fournisseurs. Le seul texte contraignant est un règlement adopté par la Commission européenne en vertu de la directive NIS 2 : le règlement d’exécution (UE) 2024/2690. Il définit les règles détaillées de l’article 21, notamment une politique relative aux fournisseurs, pour certains prestataires de services numériques tels que les fournisseurs de services cloud et de services gérés.
| Document | Ce qu'il en est des fournisseurs | Qui est concerné ? | Est-ce contraignant ? | Base |
|---|---|---|---|---|
| NIS2 (directive (UE) 2022/2555), article 21, paragraphe 2, point d), et paragraphe 3 | La sécurité de la chaîne d'approvisionnement, notamment les relations avec les fournisseurs directs ; les vulnérabilités des fournisseurs directs ; la qualité des produits des fournisseurs, leurs pratiques en matière de cybersécurité et leurs procédures de développement sécurisées | Entités essentielles et importantes | Oui, par le biais de la législation nationale | directive européenne |
| NIS2, considérant 85 | Cite des éditeurs de logiciels ; recommande de négocier des clauses contractuelles avec les fournisseurs directs ; d'autres niveaux de fournisseurs pourraient être envisagés | Entités essentielles et importantes | Non | Le considérant, une aide à l'interprétation |
| Règlement d'exécution (UE) 2024/2690 de la Commission, du 17 octobre 2024 | Politique de sécurité de la chaîne d'approvisionnement destinée aux fournisseurs directs, assortie de critères de sélection | Types d'entités numériques répertoriés, tels que les fournisseurs de services cloud et de services gérés | Oui, pour ce genre de cas | Acte d'exécution |
| Guide technique de mise en œuvre de l'ENISA, version 1.0, juin 2025 | Conseils pratiques et exemples illustrant le règlement d'application | Types d'entités numériques répertoriés ; peuvent servir d'information à d'autres | Non | Recommandations de l'ENISA |
| Boîte à outils de l'UE pour la sécurité de la chaîne d'approvisionnement dans le secteur des TIC, février 2026 | Approche commune pour évaluer et atténuer les risques liés à la chaîne d'approvisionnement des TIC | États membres et acteurs publics et privés | Non, volontaire | Recommandations du groupe de coopération NIS |
Les responsables de projets open source pourraient ne pas être considérés comme des fournisseurs directs
Le considérant 85 de la directive NIS 2 cite les éditeurs de logiciels parmi les fournisseurs dont les risques sont à prendre en compte, et il indique que les entités pourraient envisager d’étendre leur analyse au-delà des fournisseurs directs. Les considérants ne créent toutefois pas d’obligations en soi, et les relations avec les fournisseurs visées à l’article 21 sont celles avec les fournisseurs directs.
Les lignes directrices de l'ENISA de juillet 2026 relatives aux marchés publics dans le domaine de la cybersécurité des hôpitaux et des prestataires de soins de santé abordent la question de savoir si un responsable de maintenance d'un logiciel libre peut être considéré comme un fournisseur direct, du moins dans le secteur de la santé.
Selon l'ENISA : « En ce qui concerne les logiciels libres et open source (OSS), les entités qui assurent la maintenance et la distribution de ces logiciels de manière ouverte ne peuvent pas être considérées comme des prestataires de services directs. »
Cela vaut, précisent les lignes directrices, lorsqu’il n’existe aucune relation contractuelle avec le projet au-delà d’une licence de droits d’auteur standard, ou lorsque le contrat est conclu avec un « gestionnaire de logiciel libre ». Ce terme est défini dans une autre loi, la loi sur la cyber-résilience, et désigne une personne morale, autre qu’un fabricant, qui soutient de manière durable le développement de certains produits libres.
Ces lignes directrices sont non contraignantes et ont été rédigées dans le cadre des marchés publics du secteur de la santé ; elles ne déterminent donc pas la manière dont une autorité nationale interprétera l’article 21. Elles sont conformes au texte de la directive, qui n’exige nulle part expressément qu’une entité procède à une vérification des responsables d’un projet open source. Le risque lié au code lui-même relève toujours des mesures prévues à l’article 21, mais pas nécessairement de celles relatives à la sécurité de la chaîne d’approvisionnement.
Un fournisseur peut intégrer du logiciel libre dans un produit, un prestataire de services peut le fournir dans le cadre d’un service, ou vos propres développeurs peuvent l’ajouter au logiciel que vous développez. Le fournisseur ou le prestataire est généralement votre fournisseur direct ; par conséquent, les critères énoncés à l’article 21, paragraphe 3, y compris le développement sécurisé, s’appliquent à lui. Lorsque vos propres développeurs intègrent du logiciel libre, il se peut qu’il n’y ait pas de fournisseur au sens contractuel du terme. L’article 21, paragraphe 2, point e), relatif à la sécurité dans l’acquisition, le développement et la maintenance des systèmes d’information et de réseau, y compris la gestion des vulnérabilités, correspond mieux à ce cas de figure que la mesure relative à la sécurité de la chaîne d’approvisionnement.
Si vous vendez des logiciels, vous pouvez être le fournisseur direct auquel vos clients s’adressent. La norme NIS2 s’applique aux organisations en fonction de leur secteur d’activité et de leur taille ; le simple fait d’être le fournisseur d’une autre entité ne vous fait donc pas, en soi, entrer dans son champ d’application. Vous aurez des obligations qui vous sont propres si votre entreprise est elle-même une entité essentielle ou importante. Quel que soit votre statut, les mesures mises en place par vos clients peuvent les amener à vous demander comment vous développez et assurez la maintenance des produits que vous leur fournissez.
Là où les questionnaires s'arrêtent et où vos propres vérifications commencent
La directive NIS2 ne prévoit pas de contrôles spécifiques pour les paquets open source. Les contrôles ci-dessous constituent des mesures pratiques qui s'inscrivent dans le cadre de l'article 21, paragraphe 2, point e), et de la gestion des vulnérabilités qui y est prévue.
L'évaluation d'un fournisseur fonctionne parce que vous pouvez lui poser des questions. Vous envoyez un questionnaire, vous avez un contrat, et le fournisseur a tout intérêt à répondre. Lorsque vos propres développeurs intègrent des composants open source, cela ne s'applique guère au responsable de maintenance, qui a publié son code sous une licence et n'a peut-être jamais entendu parler de vous. Un questionnaire ne suffit pas à lui seul à vérifier que le paquet que vous utilisez correspond bien au code publié par ses responsables de maintenance, et en l’absence de fournisseur à qui l’envoyer, il n’y a généralement personne chargé de le contrôler avant qu’il ne vous parvienne. Un responsable de maintenance qui a cessé de publier des correctifs peut également ne pas répondre à une question relative à la sécurité.
Il reste donc à vérifier le paquet lui-même. Correspond-il au code source publié ? Contient-il des éléments malveillants ? Y a-t-il encore quelqu’un qui assure le suivi de la version que vous utilisez ? Votre équipe doit s’assurer que ces vérifications sont bien effectuées, que ce soit par ses propres moyens ou en recourant à un service spécialisé.
Vous aurez également besoin d’un registre répertoriant le contenu de votre logiciel et l’origine de chaque élément, car vous ne pourrez pas répondre aux questions de type « fournisseur » concernant des composants que vous ne pouvez pas énumérer. Les documents habituels sont une nomenclature logicielle (SBOM) et des données de provenance indiquant d’où provient un élément et comment il a été construit. Une déclaration VEX (Vulnerability Exploitability eXchange) ajoute le statut des vulnérabilités connues dans un produit. La fiabilité de chacun de ces documents dépend de celui qui l’a produit ; vérifiez donc qui en est l’auteur et quand il a été mis à jour pour la dernière fois.
Les organes de direction approuvent les mesures prévues à l'article 21 et peuvent être tenus pour responsables
En vertu de l’article 20, paragraphe 1, les États membres doivent veiller à ce que les organes de direction des entités essentielles et importantes approuvent les mesures prévues à l’article 21, supervisent leur mise en œuvre et puissent être tenus pour responsables des infractions commises par l’entité au titre de l’article 21. Cette disposition ne précise pas si les membres à titre individuel sont personnellement responsables. La règle explicite concernant les personnes physiques figure à l’article 32, paragraphe 6. Les États membres doivent prévoir la possibilité de tenir pour responsables les personnes habilitées à représenter, à prendre des décisions au nom ou à contrôler une entité essentielle lorsqu’elles manquent à leur obligation de veiller au respect des dispositions, et l’article 33, paragraphe 5, étend cette disposition aux entités importantes.
La formation joue également un rôle important : en vertu de l'article 20, paragraphe 2, les membres des organes de direction doivent suivre une formation leur permettant d'identifier les risques et d'évaluer les pratiques de gestion des risques liés à la cybersécurité, ainsi que leur impact sur les services de l'entité.
Un organe de direction chargé d’approuver des mesures destinées exclusivement aux fournisseurs sous contrat a approuvé précisément ce champ d’application. La directive couvre toujours le risque lié aux composants open source ajoutés par vos développeurs. Le problème est que ce risque peut, lors de la rédaction des mesures, ne se retrouver rattaché ni aux mesures de sécurité de la chaîne d’approvisionnement ni à celles relatives au développement mentionnées au point (e), et qu’un organe de direction consultant le registre des fournisseurs risque de ne jamais le remarquer. Demandez à la personne chargée de rédiger les mesures laquelle couvre les vérifications de ce code et qui les effectue.
Réduire l'écart entre les évaluations des fournisseurs et vos projets de construction
Pour les codes open source fournis sans contrat de fournisseur, SecureChain de TuxCare effectue ces trois vérifications directement sur le paquet lui-même. Il analyse le code open source à la recherche de logiciels malveillants cachés, recompile les paquets open source à partir de ce code analysé dans des environnements renforcés et isolés, et bloque tout élément non conforme avant qu’il n’atteigne votre environnement. Les paquets actifs sont corrigés dans le cadre d’un accord de niveau de service (SLA) et, une fois la maintenance en amont terminée, le service Endless Lifecycle Support (ELS) continue de fournir les correctifs. La couverture s’étend à JavaScript, Python, Java, Go et PHP, et les versions sont accompagnées d’une provenance de niveau 3 selon la norme SLSA (Supply-chain Levels for Software Artifacts), de SBOM et d’enregistrements VEX.
Si vous ne savez pas quels éléments ont été utilisés lors d'une compilation, ou si des vulnérabilités restent non corrigées sur des paquets dont plus personne n'assure la maintenance, découvrez comment SecureChain enregistre chaque compilation et applique les correctifs à ces paquets.
FAQ
Comment la directive NIS2 aborde-t-elle la question de la sécurité de la chaîne d'approvisionnement ?
La directive NIS2 de l'UE relative à la cybersécurité mentionne la sécurité de la chaîne d'approvisionnement parmi les dix mesures minimales énoncées à l'article 21. Cette mesure porte notamment sur l'aspect sécuritaire des relations d'une entité avec ses fournisseurs directs ou ses prestataires de services. L'article 21, paragraphe 3, impose aux entités d'évaluer les vulnérabilités de chaque fournisseur direct, ainsi que la qualité de ses produits et la sécurité de ses procédures de développement.
Qui doit respecter les mesures relatives à la chaîne d'approvisionnement prévues par la directive NIS 2 ?
Entités essentielles et importantes. La directive NIS2 de l'Union européenne relative à la cybersécurité classe les organisations en deux catégories en fonction du caractère critique de leur secteur ou de leur service et de leur taille. Elle s'applique généralement aux organisations de taille moyenne et aux grandes organisations des secteurs qu'elle énumère, ainsi qu'à certaines organisations de plus petite taille qui répondent à des critères spécifiques.
La directive NIS 2 impose-t-elle des obligations aux fournisseurs ?
Pas directement. Dans ses lignes directrices de juillet 2026 relatives aux marchés publics destinés aux hôpitaux, l’ENISA, l’agence européenne chargée de la cybersécurité, précise que la directive NIS 2 n’impose pas directement d’exigences aux fournisseurs de technologies de l’information et de la communication (TIC). Les clients relevant de la directive NIS 2 peuvent toutefois demander des garanties à leurs fournisseurs dans le cadre de leurs propres mesures.
Les recommandations de l'ENISA concernant la sécurité de la chaîne d'approvisionnement dans le cadre de la directive NIS 2 sont-elles contraignantes ?
Non. L’ENISA, l’agence de cybersécurité de l’Union européenne, précise que ses « lignes directrices techniques de mise en œuvre » de juin 2025 n’ont pas de caractère contraignant. Elles viennent étayer le règlement d’exécution (UE) 2024/2690 de la Commission, qui s’applique aux types d’entités numériques répertoriés, tels que les fournisseurs de services cloud et de services gérés. Les lignes directrices de l’ENISA de juillet 2026 relatives aux marchés publics hospitaliers constituent également des recommandations.
Quel peut être le montant maximal des amendes prévues par le NIS2 en cas de non-respect des mesures prévues à l'article 21 ?
En vertu de l’article 34 de la directive NIS2, relative à la cybersécurité dans l’Union européenne, les États membres doivent fixer des amendes maximales d’au moins 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial total pour les entités essentielles, et d’au moins 7 millions d’euros ou 1,4 % pour les entités importantes, le montant le plus élevé étant retenu. Le chiffre d’affaires correspond au chiffre de l’exercice financier précédent pour l’ensemble de l’entreprise à laquelle appartient l’entité. Les amendes s’appliquent aux infractions à l’article 21 ou aux règles de notification des incidents prévues à l’article 23, et ce sont les législations nationales qui fixent les montants exacts.
La directive NIS2 s'applique-t-elle de la même manière dans tous les pays de l'UE ?
Non. Les obligations s'imposent aux entités en vertu du droit national de chaque État membre, de sorte que les modalités varient d'un pays à l'autre. De nombreux États membres ont désormais des lois en vigueur, même si la plupart n'ont pas respecté la date limite d'octobre 2024 pour leur adoption. En juillet 2026, la Commission européenne a saisi la Cour de justice de l'Union européenne à l'encontre de l'Irlande, de l'Espagne, de la France et des Pays-Bas pour ne pas avoir notifié la transposition complète de la législation. Vérifiez la législation en vigueur dans chaque pays où vous exercez vos activités.
