NIS2 et sécurité de la chaîne d’approvisionnement : analyse approfondie

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).

In practice, regulators are not asking whether you “care about suppliers”. They expect you to:

  • 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

What “Supply Chain” Means Under NIS2

Most organizations underestimate what “supply chain” covers. Under NIS2, your supply chain typically includes:

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.

Translation: supply chain security is not optional, and you are expected to justify your choices using recognized risk inputs and “state of the art” practices.


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 :

  1. Gouvernance des fournisseurs
  2. Contrôles de livraison sécurisée (CI/CD)
  3. Intégrité et provenance
  4. Surveillance continue
  5. 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

Under NIS2, CI/CD is not just a delivery tool—it’s your primary enforcement layer against supply chain compromise.

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)

These measures align with the “risk-management measures” approach under 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) Integrity, Provenance, and “What Did We Actually Deploy?”

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)

This aligns with the direction of “state-of-the-art” technical measures and is heavily supported by ENISA supply-chain practice guidance. 

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

NIS2 supply chain security is not “assess once and forget”. Your supplier risk posture changes when:

  • 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

ENISA’s supply-chain guidance emphasizes continuous practices rather than static compliance artifacts. 

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 impactant vos opérations
  • capacité de révocation :
    • tokens, runners, relations de confiance
  • chemins d’escalade fournisseur et délais de signalement

NIS2 focuses strongly on operational security measures and incident readiness; ENISA’s technical guidance and related material strongly influence supervisory expectations. 

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 :

  • “We don’t know which suppliers are critical”
  • “CI/CD has broad privileges and no monitoring”
  • “We can’t prove what was deployed”
  • “We don’t retain logs long enough”
  • “Supplier exceptions are informal and undocumented”

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 ?

If you answer “no” to several of these, your NIS2 supply chain risk exposure is likely significant.


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é


Contexte “audit-ready”

Contenu conçu pour les environnements réglementés : contrôles avant outils, enforcement par politiques dans le CI/CD, et evidence-by-design pour l’audit.

Focus sur la traçabilité, les approbations, la gouvernance des exceptions et la rétention des preuves de bout en bout.

Voir la méthodologie sur la page About.