Que montrer aux auditeurs (CI/CD, fournisseurs, chaîne d’approvisionnement logicielle)
La sécurité de la chaîne d’approvisionnement est l’un des domaines les plus scrutés sous la directive NIS2. Les auditeurs et les autorités de supervision ne cherchent pas des déclarations de risques théoriques — ils attendent des preuves concrètes, générées par les systèmes, montrant comment les risques de cybersécurité liés aux fournisseurs sont identifiés, contrôlés, surveillés et traités.
Cet article fournit un pack de preuves pratique pour la chaîne d’approvisionnement NIS2, décrivant ce que les auditeurs demandent généralement et ce que les organisations doivent être en mesure de démontrer en pratique, particulièrement dans les environnements reposant sur des pipelines CI/CD et des services tiers.
Il couvre à la fois les attentes transversales et les considérations spécifiques au secteur pour les institutions financières et les entités du secteur public.
Objectif de ce pack de preuves
L’objectif de ce pack de preuves est de :
- structurer la préparation d’audit autour des faits et des preuves,
- éviter l’improvisation lors des revues de supervision,
- aligner la gouvernance fournisseur avec l’application CI/CD,
- démontrer la conformité aux mesures de gestion des risques de cybersécurité NIS2.
Ce pack se concentre sur les preuves, pas sur les outils ou les politiques isolément.
Périmètre de la chaîne d’approvisionnement sous NIS2
Sous NIS2, la chaîne d’approvisionnement inclut généralement :
- fournisseurs de logiciels soutenant des services critiques ou publics,
- plateformes CI/CD et outils de développement,
- fournisseurs de services cloud et d’infrastructure,
- services de sécurité et de surveillance managés,
- partenaires de développement ou de maintenance externalisés,
- registres d’artefacts et écosystèmes de paquets.
Les auditeurs attendent que ce périmètre soit explicitement documenté et aligné sur les cadres de gestion des risques ICT.
Considérations de périmètre spécifiques au secteur
Les institutions financières doivent également prendre en compte : les dépendances inter-institutionnelles, le risque de concentration entre fournisseurs partagés, et l’alignement avec les attentes réglementaires du secteur financier (ex : chevauchement avec DORA).
Les entités du secteur public doivent également prendre en compte : les prestataires inter-agences ou partagés, les cadres nationaux de marchés publics, et les exigences de souveraineté des données.
1. Identification des fournisseurs et classification de criticité
Ce que les auditeurs demandent généralement
Comment identifiez-vous les fournisseurs et évaluez-vous les risques de cybersécurité de la chaîne d’approvisionnement ?
Preuves à fournir
- Un inventaire des fournisseurs maintenu incluant les éditeurs de logiciels, les fournisseurs SaaS, les plateformes CI/CD, les services cloud et d’infrastructure.
- Classification de criticité des fournisseurs (critique / important / non critique).
- Critères d’évaluation des risques basés sur : l’impact métier, le niveau d’accès, la sensibilité des données, la dépendance opérationnelle et la substituabilité.
- Désignation claire de la propriété fournisseur au sein de l’organisation.
Exemples de preuves attendues
- Registre fournisseur ou export d’inventaire avec la criticité clairement indiquée
- Méthodologie de scoring ou de classification des risques
- Correspondance des fournisseurs avec les services ou systèmes supportés
Notes sectorielles
Finance : L’absence de classification de criticité claire est un constat de haute sévérité fréquent dans les audits financiers. Le risque de concentration doit également être évalué.
Secteur public : L’absence de responsabilité et de propriété claire des fournisseurs est un constat d’audit fréquent. Les processus de gouvernance fournisseur doivent être documentés même lorsque les services sont partagés entre plusieurs entités.
2. Exigences de sécurité fournisseur et contrôles contractuels
Ce que les auditeurs demandent généralement
Comment les exigences de cybersécurité sont-elles appliquées aux fournisseurs ?
Preuves à fournir
- Exigences de sécurité intégrées dans les processus d’achat.
- Clauses contractuelles couvrant : les obligations de cybersécurité, les délais de notification d’incident, le droit d’audit ou d’assurance, et la continuité de service.
- Attentes de sécurité minimales définies pour les fournisseurs critiques.
Exemples de preuves attendues
- Extraits de contrats (sections liées à la sécurité uniquement)
- Avenants de sécurité fournisseur
- Checklists d’achat ou d’intégration fournisseur
Les auditeurs n’exigent généralement pas les contrats complets — des extraits ciblés suffisent. Ils se concentrent sur la cohérence et l’applicabilité, pas sur le détail juridique.
Notes sectorielles
Finance : L’alignement contractuel avec les attentes réglementaires du secteur financier est attendu le cas échéant.
Secteur public : Les auditeurs comprennent les contraintes d’achat mais attendent de la cohérence et de la traçabilité. L’alignement avec les cadres nationaux d’achat et réglementaires est évalué.
3. Contrôles CI/CD soutenant la sécurité de la chaîne d’approvisionnement
Ce que les auditeurs demandent généralement
Comment les pipelines CI/CD réduisent-ils le risque de la chaîne d’approvisionnement ?
Preuves à fournir
- Pipelines CI/CD appliquant : branches protégées et revue de code, accès restreint à la modification des pipelines, contrôles de gestion des secrets.
- Utilisation obligatoire des pipelines CI/CD pour tous les changements en production.
- Contrôle d’accès fort (RBAC, MFA) sur les plateformes CI/CD.
- Séparation des fonctions appliquée par les workflows d’approbation.
- Analyse des dépendances (SCA) intégrée dans les pipelines.
- Application des politiques bloquant les builds ou déploiements en cas de risque critique.
Exemples de preuves attendues
- Définitions de pipelines CI/CD (exports YAML ou configuration)
- Exemple de pipeline échoué suite à une violation de dépendance ou de politique
- Journaux d’approbation et de déploiement
- Captures d’écran de la configuration du contrôle d’accès
Notes sectorielles
Finance : Les pipelines CI/CD sont traités comme des systèmes ICT réglementés, pas comme des outils de développement. Les auditeurs demandent souvent des démonstrations de traçabilité de bout en bout lors des revues.
Secteur public : Les pipelines CI/CD sont évalués principalement comme des mécanismes de gestion des changements et de traçabilité. Les auditeurs se concentrent généralement moins sur la sophistication des outils que sur l’application. Les changements d’urgence doivent rester traçables.
4. Intégrité des dépendances et des artefacts
Ce que les auditeurs demandent généralement
Comment savez-vous que le logiciel déployé n’a pas été altéré ?
Preuves à fournir
- Software Bill of Materials (SBOM) pour les releases critiques.
- Liaison de provenance : code source → exécution du build → artefact généré → déploiement en production.
- Contrôles d’intégrité des artefacts (signature, vérification, registres de confiance).
- Inventaires de dépendances et analyse de vulnérabilités.
- Procédures de traitement des vulnérabilités critiques dans les composants tiers.
Exemples de preuves attendues
- Fichiers SBOM pour des releases représentatives
- Métadonnées du dépôt d’artefacts
- Trace de déploiement montrant commit → artefact → production
- Enregistrements d’acceptation de risque ou de remédiation
Notes sectorielles
Finance : L’incapacité à démontrer la traçabilité est souvent escaladée comme un risque matériel.
Secteur public : Les SBOMs sont de plus en plus attendus pour les services publics critiques mais peuvent être appliqués de manière proportionnée selon la maturité technique.
5. Accès tiers et gestion des privilèges
Ce que les auditeurs demandent généralement
Les fournisseurs ou les outils tiers ont-ils un accès privilégié ?
Preuves à fournir
- Inventaire des comptes tiers et de service.
- Justification du moindre privilège pour chaque accès privilégié.
- Revues d’accès périodiques et recertification.
- Processus d’approbation formels pour les accès privilégiés des fournisseurs.
- Procédures de révocation d’accès définies.
Exemples de preuves attendues
- Listes de rôles IAM et de permissions
- Rapports de revue d’accès
- Tickets d’approbation ou enregistrements de workflow
- Preuves de révocation ou de décommissionnement
Notes sectorielles
Finance : Les comptes de service CI/CD avec des privilèges excessifs sont un constat d’audit courant.
Secteur public : Les comptes fournisseurs de longue durée sans revue sont un problème d’audit courant.
6. Surveillance et détection des événements de la chaîne d’approvisionnement
Ce que les auditeurs demandent généralement
Comment détectez-vous les événements de sécurité liés à la chaîne d’approvisionnement ?
Preuves à fournir
- Surveillance de : l’activité des pipelines CI/CD, les alertes de vulnérabilité des dépendances, les comportements tiers anormaux, les événements d’accès fournisseur.
- Seuils d’alerte définis et chemins d’escalade.
- Intégration avec le SOC ou les fonctions de surveillance de sécurité.
Exemples de preuves attendues
- Règles SIEM ou de surveillance
- Exemples d’alertes ou d’investigations liées aux dépendances ou anomalies de pipeline
- Tickets d’incident liés à des événements fournisseur
Notes sectorielles
Finance : L’intégration avec le SOC et les fonctions de surveillance de sécurité est attendue.
Secteur public : Les auditeurs se concentrent sur la sensibilisation et la capacité de réponse, pas nécessairement sur l’analytique avancée.
7. Réponse aux incidents et coordination fournisseur
Ce que les auditeurs demandent généralement
Que se passe-t-il si un fournisseur est compromis ?
Preuves à fournir
- Playbooks de réponse aux incidents couvrant : dépendances compromises, composants CI/CD compromis, incidents de sécurité fournisseur.
- Procédures de révocation et de confinement.
- Chemins d’escalade et de communication fournisseur.
Exemples de preuves attendues
- Extraits de playbooks de réponse aux incidents
- Enregistrements d’exercices de simulation ou de tests
- Rapports de revue post-incident (le cas échéant)
Notes sectorielles
Finance : Les superviseurs évaluent à la fois la préparation et la capacité d’exécution.
Secteur public : Les mécanismes de coordination avec les parties prenantes internes, les autres entités publiques et les autorités nationales (le cas échéant) sont évalués. La préparation et la clarté des rôles sont des critères clés.
8. Conservation des preuves et auditabilité
Ce que les auditeurs demandent généralement
Pouvez-vous retrouver des preuves historiques de la chaîne d’approvisionnement ?
Preuves à fournir
- Périodes de conservation définies pour : journaux CI/CD, résultats d’analyses de sécurité, enregistrements liés aux fournisseurs, enregistrements de déploiement.
- Stockage de preuves centralisé et protégé.
- Capacité de récupération démontrée.
Exemples de preuves attendues
- Documentation de la politique de conservation
- Configuration de la conservation de la plateforme de journalisation
- Exemple de récupération de journal ou rapport historique
Notes sectorielles
Secteur public : La traçabilité à long terme est particulièrement importante en raison des exigences de marchés publics et de responsabilité.
Constats d’audit courants
Les auditeurs identifient fréquemment des problèmes tels que :
- inventaires de fournisseurs incomplets,
- absence de classification de criticité des fournisseurs,
- pipelines CI/CD avec des privilèges excessifs ou exclus du périmètre de risques ICT,
- conservation insuffisante des preuves,
- exceptions fournisseurs non documentées,
- acceptation informelle du risque fournisseur,
- pipelines CI/CD contournés pour les correctifs urgents (secteur public),
- documentation faible des incidents fournisseurs.
Traiter ces lacunes de manière proactive réduit significativement le risque de conformité NIS2.
Constats spécifiques au secteur financier
- Plateformes CI/CD exclues du périmètre de risques ICT
- Privilèges excessifs dans les comptes d’automatisation
- Classification de criticité floue pour l’infrastructure partagée
Constats spécifiques au secteur public
- Responsabilité fournisseur floue
- Acceptation informelle du risque sans documentation
- Conservation insuffisante des preuves pour les longs cycles d’audit
Conclusion
La conformité NIS2 de la chaîne d’approvisionnement ne s’obtient pas par la seule documentation. Elle nécessite une application opérationnelle, des contrôles techniques et une génération continue de preuves à travers les fournisseurs, les pipelines CI/CD et les systèmes de production.
Les organisations qui traitent les pipelines CI/CD comme des points d’application pour la sécurité de la chaîne d’approvisionnement — et maintiennent des preuves structurées et récupérables — sont les mieux positionnées pour répondre aux attentes de supervision NIS2 avec confiance.
Cela s’applique à tous les secteurs : les institutions financières doivent démontrer un contrôle systémique des risques et un alignement réglementaire, tandis que les entités du secteur public doivent démontrer une gouvernance, une responsabilité et des contrôles proportionnés adaptés à leurs contraintes opérationnelles.
Contenu associé
- NIS2 Security Architecture — Explained
- NIS2 Supply Chain Security Deep Dive
- Supplier Governance & CI/CD Controls Checklist
- How Auditors Actually Review CI/CD Pipelines
