La sécurité de la chaîne d’approvisionnement est l’un des aspects les plus complexes sur le plan opérationnel de NIS2. Elle oblige les entités essentielles et importantes à aller au-delà des contrôles internes et à traiter les risques introduits par les fournisseurs, les prestataires de services, les dépendances logicielles et les opérations ICT externalisées.
Cette analyse approfondie explique ce que NIS2 attend en pratique, comment traduire les exigences en contrôles CI/CD et fournisseurs, et quelles preuves les auditeurs demandent généralement.
Pourquoi la sécurité de la chaîne d’approvisionnement est une exigence fondamentale de NIS2
NIS2 rend obligatoire la gestion des risques de cybersécurité et inclut explicitement la chaîne d’approvisionnement et les relations fournisseurs dans les mesures requises. La sécurité de la chaîne d’approvisionnement est référencée dans les mesures de gestion des risques de cybersécurité de l’Article 21(2).
En pratique, les régulateurs ne se demandent pas si vous « vous souciez de vos fournisseurs ». Ils attendent de vous que vous :
- identifiiez les risques liés aux fournisseurs
- appliquiez des contrôles proportionnés
- surveilliez la performance des fournisseurs
- prouviez les décisions et leur application
Ce que recouvre la « chaîne d’approvisionnement » au sens de NIS2
La plupart des organisations sous-estiment ce que recouvre la « chaîne d’approvisionnement ». Selon NIS2, votre chaîne d’approvisionnement comprend généralement :
1) Chaîne d’approvisionnement logicielle
- dépendances open source
- outils de build et plugins
- images de base de conteneurs
- registres d’artefacts
- dépôts de paquets
2) Chaîne d’approvisionnement CI/CD et plateforme développeur
- Fournisseurs CI (GitHub Actions, GitLab CI, écosystème Jenkins)
- runners/agents et leurs images
- gestionnaires de secrets
- plateformes d’hébergement de code et d’identité
3) Chaîne d’approvisionnement de services ICT
- fournisseurs cloud (IaaS/PaaS)
- services de sécurité managés
- fournisseurs de surveillance/journalisation
- SaaS critiques pour les opérations (ticketing, identité, etc.)
Les recommandations ENISA sur la chaîne d’approvisionnement traitent explicitement la cybersécurité de la chaîne d’approvisionnement comme partie intégrante de la gestion des risques NIS2.
L’ossature réglementaire : Article 21 + Article 22
NIS2 exige des mesures techniques/opérationnelles/organisationnelles dans l’Article 21(2), et exige explicitement la prise en compte des résultats des évaluations coordonnées des risques de la chaîne d’approvisionnement au titre de l’Article 22 lors de la détermination des mesures appropriées.
Autrement dit : la sécurité de la chaîne d’approvisionnement n’est pas optionnelle, et vous êtes tenu de justifier vos choix en vous appuyant sur des données de risque reconnues et sur des pratiques conformes à « l’état de l’art ».
Un modèle de contrôle pratique pour la sécurité de la chaîne d’approvisionnement NIS2
Pour rendre la sécurité de la chaîne d’approvisionnement auditable, vous avez besoin d’un modèle de contrôle couvrant :
- Gouvernance des fournisseurs
- Contrôles de livraison sécurisée (CI/CD)
- Intégrité et provenance
- Surveillance continue
- Traitement des incidents et coordination
Voici une décomposition éprouvée sur le terrain.
1) Contrôles de gouvernance des fournisseurs
Ce que recherchent les auditeurs
Les auditeurs commencent généralement par vérifier si le risque fournisseur est géré comme un processus reproductible, et non un questionnaire ponctuel.
Contrôles à implémenter
- Inventaire des fournisseurs (critiques vs non critiques)
- Critères de classification des risques (sensibilité des données, impact opérationnel, accès privilégié)
- Exigences de sécurité intégrées dans les achats et les contrats
- Gouvernance des accès tiers (accès JIT, moindre privilège, approbations)
- Revues périodiques pour les fournisseurs critiques (posture de sécurité, changements, incidents)
Les bonnes pratiques ENISA pour la chaîne d’approvisionnement fournissent des orientations pratiques pour structurer ces contrôles.
Preuves à conserver (minimum)
- registre des fournisseurs + classification
- clauses de sécurité contractuelles pour les fournisseurs critiques
- journaux d’accès tiers (le cas échéant)
- rapports de revue et suivis de remédiation
2) Contrôles CI/CD réduisant le risque de la chaîne d’approvisionnement
Selon NIS2, le CI/CD n’est pas un simple outil de livraison : c’est votre principale couche d’application des contrôles contre la compromission de la chaîne d’approvisionnement.
Contrôles à implémenter dans le CI/CD
- Revue de code obligatoire et branches protégées
- Hygiène des secrets (pas de secrets dans le dépôt, injection au runtime, rotation)
- Analyse des dépendances (SCA) et application des politiques
- SAST/DAST lorsque pertinent (pas spécifique à la chaîne d’approvisionnement, mais soutient la livraison sécurisée)
- Isolation du build (runners durcis, permissions minimales, agents de build éphémères)
Ces mesures s’inscrivent dans l’approche des « mesures de gestion des risques » prévue à l’Article 21(2).
Preuves à conserver
- définitions de pipelines montrant les étapes appliquées
- journaux des portes de politique (builds/releases bloqués)
- rapports d’analyse des dépendances
- configuration des runners (durcissement / éphémère)
3) Intégrité, provenance et « qu’avons-nous réellement déployé ? »
La sécurité de la chaîne d’approvisionnement devient réelle lorsque vous pouvez prouver :
- ce que vous avez construit
- à partir de quelle source
- avec quelles dépendances
- et si l’artefact a été altéré
Contrôles à implémenter
- Génération de SBOM pour les releases (au moins pour les systèmes critiques)
- Enregistrements de provenance reliant commit → build → artefact → déploiement
- Signature d’artefacts et vérification avant déploiement
- Registres de confiance (restreindre les pulls externes, épingler versions/digests)
Cela va dans le sens des mesures techniques relevant de « l’état de l’art » et s’appuie largement sur les recommandations pratiques de l’ENISA en matière de chaîne d’approvisionnement.
Preuves à conserver
- SBOMs pour les releases
- signatures et journaux de vérification
- journaux du dépôt d’artefacts (publication, pull, permissions)
4) Surveillance continue du risque fournisseur
La sécurité de la chaîne d’approvisionnement NIS2 ne consiste pas à « évaluer une fois puis oublier ». Le niveau de risque de vos fournisseurs évolue lorsque :
- un fournisseur change d’infrastructure
- une vulnérabilité majeure apparaît
- les schémas d’accès changent
- des incidents surviennent
Contrôles à implémenter
- surveillance de :
- pics de vulnérabilités de dépendances (CVE critiques)
- activité anormale des pipelines (exécutions de workflows inattendues, nouveaux runners)
- anomalies d’accès tiers
- notifications de changements fournisseurs (surtout pour les fournisseurs critiques)
- rafraîchissement périodique de l’assurance fournisseur pour les fournisseurs à haut risque
Les recommandations de l’ENISA sur la chaîne d’approvisionnement mettent l’accent sur des pratiques continues plutôt que sur des artefacts de conformité statiques.
Preuves à conserver
- règles d’alerte et incidents liés aux fournisseurs / anomalies CI/CD
- rapports de tendances de vulnérabilités (pour les applications critiques)
- cadence des revues d’assurance fournisseur
5) Gestion des incidents et coordination fournisseur
Les incidents de chaîne d’approvisionnement sont complexes car la responsabilité est partagée. Les auditeurs attendent que vous puissiez répondre rapidement et coordonner les preuves.
Contrôles à implémenter
- playbooks de réponse aux incidents couvrant :
- identifiants de pipeline compromis
- dépendance compromise / paquet malveillant
- brèche fournisseur affectant vos opérations
- capacité de révocation :
- tokens, runners, relations de confiance
- chemins d’escalade fournisseur et délais de signalement
NIS2 met fortement l’accent sur les mesures de sécurité opérationnelle et la préparation aux incidents ; les orientations techniques de l’ENISA et les documents connexes influencent fortement les attentes des autorités de contrôle.
Preuves à conserver
- Playbooks de réponse aux incidents et exercices de simulation
- tickets d’incidents et chronologies
- rapports de revue post-incident et actions correctives
Réalité d’audit : comment les constats de chaîne d’approvisionnement se produisent
Les constats courants NIS2 sur la chaîne d’approvisionnement suivent généralement quelques schémas :
- « Nous ne savons pas quels fournisseurs sont critiques »
- « Le CI/CD dispose de privilèges étendus et d’aucune surveillance »
- « Nous ne pouvons pas prouver ce qui a été déployé »
- « Nous ne conservons pas les journaux assez longtemps »
- « Les dérogations accordées aux fournisseurs sont informelles et non documentées »
Une posture solide de chaîne d’approvisionnement repose principalement sur la gouvernance + application + preuves, pas uniquement sur les outils.
Checklist d’auto-évaluation rapide (chaîne d’approvisionnement NIS2)
Utilisez ceci comme vérification interne rapide :
- Avons-nous un inventaire des fournisseurs avec des niveaux de criticité ?
- Les fournisseurs critiques ont-ils des exigences de sécurité contractuelles ?
- Les workflows CI/CD sont-ils protégés et les accès contrôlés ?
- Analysons-nous les dépendances et appliquons-nous les politiques ?
- Pouvons-nous produire SBOM + provenance pour les releases critiques ?
- Les artefacts sont-ils signés et vérifiés ?
- Surveillons-nous les anomalies de pipeline et les alertes liées aux fournisseurs ?
- Avons-nous des playbooks pour les incidents de chaîne d’approvisionnement ?
Si vous répondez « non » à plusieurs de ces questions, votre exposition au risque de chaîne d’approvisionnement NIS2 est probablement significative.
Conclusion
La sécurité de la chaîne d’approvisionnement NIS2 n’est pas une case à cocher des achats. C’est un problème d’architecture opérationnelle qui couvre la gouvernance fournisseur, l’application CI/CD, les garanties d’intégrité et la préparation aux incidents.
Les organisations qui traitent les pipelines CI/CD comme des systèmes d’application réglementés — et construisent des preuves continues autour de l’intégrité logicielle — sont considérablement mieux positionnées pour répondre aux attentes NIS2.
Contenu associé
- Architecture de sécurité NIS2 — Expliquée
- Sécurité CI/CD
- Conformité continue via le CI/CD
- Comment les auditeurs examinent réellement les pipelines CI/CD
- Signaux d’alerte des audits CI/CD
