Sécurité de la chaîne d'approvisionnement NIS2 — Auditer les composants tiers dans le CI/CD

NIS2 Article 21(2)(d) : exigences de sécurité de la chaîne d’approvisionnement

L’article 21(2)(d) de NIS2 exige des entités essentielles et importantes qu’elles traitent la sécurité de la chaîne d’approvisionnement, y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs directs ou prestataires de services. Pour les organisations qui construisent et déploient des logiciels via des pipelines CI/CD, cette exigence a des implications considérables.

Le pipeline CI/CD moderne est, par nature, une chaîne d’approvisionnement. Chaque build incorpore des bibliothèques tierces, des images de base, des services externes et des outils provenant de multiples fournisseurs. Un seul composant compromis n’importe où dans cette chaîne peut se propager à travers les pipelines automatisés vers les environnements de production en quelques minutes. Les auditeurs doivent donc évaluer non seulement les contrôles propres de l’organisation, mais aussi le cadre de gouvernance entourant chaque élément tiers qui entre dans le pipeline de livraison.

Risques tiers dans les environnements CI/CD

Comprendre les catégories de risques tiers dans CI/CD est essentiel pour délimiter le périmètre d’un audit. Les domaines suivants représentent la surface de risque principale :

Dépendances open-source

La plupart des applications modernes intègrent des dizaines à des centaines de bibliothèques open-source. Chaque dépendance — et ses dépendances transitives — représente une vulnérabilité ou un vecteur d’attaque potentiel. Les risques incluent les vulnérabilités connues dans les paquets obsolètes, les paquets malveillants publiés sous des noms similaires (typosquatting) et les comptes de mainteneurs compromis.

Plateforme CI/CD et outils SaaS

Les organisations s’appuient fréquemment sur des plateformes SaaS tierces pour le contrôle de source, l’exécution de builds, le stockage d’artefacts et l’orchestration de déploiement. Ces plateformes ont un accès privilégié au code source, aux secrets et aux environnements de production. Une violation de l’un de ces fournisseurs pourrait compromettre l’ensemble du pipeline de livraison.

Runners de build partagés et hébergés

Les environnements de build partagés entre projets ou hébergés par des tiers introduisent des risques de contamination croisée, de fuite de données et d’isolation insuffisante. Si un runner de build est compromis, chaque pipeline qui l’utilise est potentiellement affecté.

Images de base et registres de conteneurs

Les déploiements basés sur des conteneurs dépendent d’images de base souvent sourcées depuis des registres publics. Ces images peuvent contenir des vulnérabilités, des composants inutiles qui élargissent la surface d’attaque, ou dans de rares cas, du contenu délibérément malveillant.

SCA et SBOM comme outils de gouvernance de la chaîne d’approvisionnement

Deux capacités clés soutiennent la gouvernance de la chaîne d’approvisionnement dans les environnements CI/CD. Les auditeurs doivent comprendre ce que chacune fournit et vérifier que l’organisation les utilise efficacement.

Software Composition Analysis (SCA)

Le SCA fournit une visibilité sur les composants tiers présents dans une application. Du point de vue de la gouvernance, le SCA apporte :

Inventaire des composants : Une liste complète de toutes les bibliothèques tierces et leurs versions utilisées dans chaque build
Identification des vulnérabilités : Mapping des composants par rapport aux bases de données de vulnérabilités connues
Conformité des licences : Identification des obligations de licence pouvant créer un risque juridique ou opérationnel
Application des politiques : La capacité de bloquer les builds incluant des composants interdits ou à haut risque

Les auditeurs doivent vérifier que le SCA est intégré dans le pipeline comme une porte obligatoire — et non une étape consultative optionnelle — et que les violations de politique entraînent des déploiements bloqués avec des processus d’exception documentés.

Software Bill of Materials (SBOM)

Un SBOM est un inventaire formel et lisible par machine de tous les composants d’un artefact logiciel. Pour la gouvernance de la chaîne d’approvisionnement, les SBOM fournissent :

Transparence : Un enregistrement complet de ce qui est inclus dans chaque artefact déployé
Support à la réponse aux incidents : La capacité de déterminer rapidement si une vulnérabilité nouvellement divulguée affecte un logiciel déployé
Preuve réglementaire : Preuve démontrable de la connaissance et de la gestion de la chaîne d’approvisionnement
Responsabilité des fournisseurs : Une base pour tenir les fournisseurs responsables des composants qu’ils fournissent

Les auditeurs doivent confirmer que les SBOM sont générés pour chaque mise en production, stockés avec des périodes de rétention appropriées, et que l’organisation peut les interroger pour identifier les systèmes affectés lorsque de nouvelles vulnérabilités sont divulguées.

Cadre d’évaluation des fournisseurs pour les fournisseurs d’outils CI/CD

Les organisations doivent évaluer la posture de sécurité de leurs fournisseurs d’outils CI/CD avec la même rigueur appliquée à tout prestataire de services critique. Le cadre suivant décrit les domaines clés d’évaluation :

Certifications et attestations de sécurité

Le fournisseur détient-il des certifications pertinentes (ISO 27001, SOC 2 Type II) ?
Les rapports d’audit sont-ils à jour et disponibles pour examen ?
Le fournisseur subit-il des tests d’intrusion réguliers par des évaluateurs indépendants ?

Traitement des données et isolation

Comment le fournisseur isole-t-il les données clients et les environnements de build ?
Où les données sont-elles stockées, et cela respecte-t-il les exigences applicables de résidence des données ?
Quel chiffrement est appliqué aux données au repos et en transit ?

Accès et authentification

Le fournisseur supporte-t-il et applique-t-il le MFA pour l’accès administratif ?
Quel accès le personnel du fournisseur a-t-il aux environnements et données clients ?
Les événements d’accès privilégié sont-ils journalisés et disponibles pour le client ?

Notification d’incidents

Quels sont les engagements et délais de notification d’incidents du fournisseur ?
Les SLA contractuels s’alignent-ils avec les délais de signalement de l’article 23 de NIS2 ?
Le fournisseur a-t-il démontré la notification d’incidents en pratique ?

Transparence de la chaîne d’approvisionnement

Le fournisseur divulgue-t-il ses propres dépendances tierces et sous-traitants ?
Quels contrôles le fournisseur applique-t-il à sa propre chaîne d’approvisionnement ?
Le fournisseur peut-il fournir des SBOM pour ses produits ?

Mapping des risques, contrôles et preuves de la chaîne d’approvisionnement

Risque de la chaîne d’approvisionnement	Contrôle	Preuves pour les auditeurs
Dépendance open-source vulnérable	Analyse SCA obligatoire au moment du build avec blocage basé sur les politiques des vulnérabilités critiques/élevées	Rapports d’analyse SCA par build ; documentation de la politique de blocage ; registres d’exceptions/dérogations avec justification et dates d’expiration
Injection de paquet malveillant (typosquatting, dependency confusion)	Registre de paquets approuvé avec contrôles de namespace ; épinglage des dépendances et vérification d’intégrité	Configuration du registre approuvé ; listes blanches de paquets ; journaux de vérification d’intégrité (validation checksum/signature)
Image de base compromise	Catalogue d’images de base approuvées ; analyse d’image avant utilisation ; signature et vérification d’image	Liste d’images approuvées avec dates de revue ; rapports d’analyse d’images ; registres de vérification de signature
Violation du fournisseur de plateforme CI/CD	Évaluation des risques fournisseur ; exigences contractuelles de sécurité ; planification de contingence pour la défaillance du fournisseur	Rapports d’évaluation fournisseur (à jour dans les 12 mois) ; contrats avec clauses de sécurité ; plans de continuité d’activité couvrant la perte de plateforme CI/CD
Contamination croisée des runners partagés	Environnements de build dédiés ou éphémères ; politiques d’isolation des runners ; nettoyage post-build de l’environnement	Documentation de l’architecture de l’environnement de build ; attestations de configuration d’isolation ; journaux de vérification de nettoyage
Plugin ou intégration CI/CD compromis	Processus d’approbation des plugins/intégrations ; revue périodique des plugins installés ; permissions de moindre privilège pour les intégrations	Registre des plugins approuvés ; registres de revue des plugins ; matrices de permissions pour les intégrations
Manque de traçabilité des composants	Génération de SBOM pour chaque mise en production ; stockage et capacité d’interrogation des SBOM	SBOM pour les mises en production récentes ; preuve de capacité d’interrogation SBOM (ex. réponse à une requête de vulnérabilité test) ; conformité de la politique de rétention
Verrouillage fournisseur empêchant la migration sécuritaire	Évaluation de la stratégie multi-fournisseurs ; évaluation de la portabilité des données ; planification de sortie	Analyse de dépendance fournisseur ; documentation de capacité d’export de données ; plan de sortie

Signaux d’alerte que les auditeurs doivent surveiller

Lors d’une évaluation de la sécurité de la chaîne d’approvisionnement des environnements CI/CD, les constats suivants doivent susciter une préoccupation immédiate :

Pas de politique de gouvernance des dépendances : L’organisation n’a pas de politique documentée régissant l’utilisation de composants tiers dans les builds. Cela suggère une lacune fondamentale dans la sensibilisation à la chaîne d’approvisionnement.
L’analyse SCA est uniquement consultative : Les analyses de vulnérabilités s’exécutent mais ne bloquent pas les déploiements. Les développeurs peuvent (et le font) déployer avec des vulnérabilités critiques connues. Recherchez des preuves de builds poursuivis malgré des constats de sévérité élevée.
Pas de génération de SBOM : L’organisation ne peut pas produire d’inventaire de composants pour ses logiciels déployés. Il est alors impossible d’évaluer l’exposition aux vulnérabilités nouvellement divulguées.
Évaluations fournisseurs périmées : Les fournisseurs d’outils CI/CD ont été évalués une seule fois (peut-être lors de l’approvisionnement) mais n’ont pas été réévalués. Recherchez des dates d’évaluation de plus de 12 mois.
Accès non restreint aux registres publics : Les builds extraient les dépendances directement des registres publics sans registre approuvé intermédiaire ni vérification d’intégrité. C’est une exposition directe aux attaques de dependency confusion et de typosquatting.
Pas de gouvernance des images de base : Les équipes utilisent des images de base arbitraires provenant de sources publiques sans analyse, approbation ou épinglage de version. Chaque image non vérifiée est un point d’entrée potentiel pour une compromission.
Runners partagés sans preuve d’isolation : L’organisation utilise une infrastructure de build partagée mais ne peut pas démontrer que les builds sont isolés les uns des autres.
Exigences de sécurité contractuelles manquantes : Les accords avec les fournisseurs d’outils CI/CD ne contiennent aucune clause de sécurité, aucune obligation de notification d’incident et aucun droit d’audit.
Pas de processus de gestion des exceptions : Lorsque les contrôles de la chaîne d’approvisionnement sont contournés (ex. une dépendance vulnérable est acceptée), il n’y a pas de processus d’exception formel avec justification documentée, acceptation du risque et date d’expiration.
Plugins et intégrations sans revue : Les plateformes CI/CD ont de nombreux plugins tiers installés sans preuve de revue de sécurité ou de processus d’approbation.

Checklist d’audit NIS2 pour la chaîne d’approvisionnement

Les sections ci-dessus décrivent ce que les auditeurs recherchent et pourquoi. La checklist ci-dessous transforme ces attentes en une revue structurée en dix parties qui reflète la façon dont les exigences NIS2 en matière de chaîne d’approvisionnement sont réellement examinées par les auditeurs et les autorités de supervision — en mettant l’accent sur la gouvernance, l’application technique et les preuves plutôt que sur des déclarations de principe de haut niveau. Utilisez-la pour évaluer votre préparation avant un audit, ou pour guider la préparation des preuves une fois la supervision engagée.

1. Périmètre et identification des fournisseurs

Point d’attention de l’auditeur

Tous les fournisseurs pertinents sont-ils identifiés et inclus dans le périmètre ?

Checklist

⬜ Un inventaire des fournisseurs existe et est tenu à jour
⬜ L’inventaire inclut :
- les éditeurs de logiciels
- les plateformes CI/CD
- les fournisseurs cloud et d’infrastructure
- les services ICT externalisés
⬜ Les fournisseurs sont mis en correspondance avec les services ou systèmes qu’ils soutiennent
⬜ Le périmètre de la chaîne d’approvisionnement est formellement documenté

Signaux d’alerte typiques

Fournisseurs CI/CD exclus du périmètre des fournisseurs
Listes de fournisseurs incomplètes ou obsolètes

2. Criticité des fournisseurs et classification des risques

Point d’attention de l’auditeur

Les risques de la chaîne d’approvisionnement sont-ils évalués de manière proportionnée ?

Checklist

⬜ Les fournisseurs sont classés par criticité
⬜ Les critères de classification incluent :
- l’impact sur les services essentiels
- le niveau d’accès privilégié
- la sensibilité des données
- la substituabilité
⬜ Les évaluations des risques sont documentées et reproductibles
⬜ Les fournisseurs critiques sont clairement identifiés

Signaux d’alerte typiques

Aucune distinction entre fournisseurs critiques et non critiques
Évaluations des risques réalisées de manière informelle

3. Gouvernance et responsabilité des fournisseurs

Point d’attention de l’auditeur

Qui est responsable du risque fournisseur ?

Checklist

⬜ Chaque fournisseur a un responsable interne clairement désigné
⬜ Les rôles de gouvernance des fournisseurs sont définis
⬜ Des revues périodiques des fournisseurs sont réalisées
⬜ Les risques liés aux fournisseurs sont escaladés de manière appropriée

Signaux d’alerte typiques

Responsabilité des fournisseurs floue ou implicite
Aucune preuve de supervision continue des fournisseurs

4. Contrôles liés à l’approvisionnement et aux contrats

Point d’attention de l’auditeur

Les exigences de cybersécurité sont-elles contraignantes ?

Checklist

⬜ Les exigences de cybersécurité sont intégrées à l’approvisionnement
⬜ Les contrats incluent :
- des obligations de sécurité
- des exigences de notification d’incidents
- des clauses de coopération
⬜ Les clauses de sécurité sont appliquées de manière cohérente aux fournisseurs critiques
⬜ Les exceptions contractuelles sont documentées et justifiées

Signaux d’alerte typiques

Exigences de sécurité appliquées de manière incohérente
Aucune traçabilité entre les contrats et les évaluations des risques

5. Contrôles de la chaîne d’approvisionnement CI/CD

Point d’attention de l’auditeur

Comment le risque de la chaîne d’approvisionnement est-il appliqué techniquement ?

Checklist

⬜ Les pipelines CI/CD sont obligatoires pour les changements en production
⬜ L’accès aux plateformes CI/CD est restreint (RBAC, MFA)
⬜ Les modifications des pipelines sont contrôlées et journalisées
⬜ La séparation des tâches est appliquée via des approbations
⬜ Les intégrations tierces dans le CI/CD sont gouvernées

Signaux d’alerte typiques

Déploiements manuels ou hors circuit
Comptes de service CI/CD sur-privilégiés

6. Contrôles d’intégrité des dépendances et des logiciels

Point d’attention de l’auditeur

Comment faites-vous confiance à ce que vous déployez ?

Checklist

⬜ Des inventaires de dépendances existent pour les applications critiques
⬜ L’analyse des dépendances (SCA) est réalisée
⬜ Les vulnérabilités critiques déclenchent une remédiation ou une décision
⬜ Des SBOM sont disponibles pour les systèmes critiques (le cas échéant)
⬜ L’intégrité et la provenance des artefacts sont assurées

Signaux d’alerte typiques

Aucune visibilité sur les dépendances
Incapacité à tracer les artefacts déployés

7. Gestion des accès des tiers

Point d’attention de l’auditeur

Les fournisseurs disposent-ils d’un accès contrôlé ?

Checklist

⬜ Les comptes tiers et de service sont inventoriés
⬜ L’accès suit les principes de moindre privilège
⬜ L’accès privilégié est approuvé et journalisé
⬜ Des revues d’accès périodiques sont réalisées
⬜ Des procédures de révocation des accès existent

Signaux d’alerte typiques

Comptes fournisseurs à longue durée de vie sans revue
Identifiants partagés ou non documentés

8. Surveillance et détection

Point d’attention de l’auditeur

Pouvez-vous détecter les événements liés à la chaîne d’approvisionnement ?

Checklist

⬜ L’activité des pipelines CI/CD est surveillée
⬜ Les alertes de vulnérabilité des dépendances sont surveillées
⬜ Les anomalies liées aux fournisseurs sont détectables
⬜ Les alertes ont des chemins d’escalade définis

Signaux d’alerte typiques

Des journaux existent mais ne sont pas examinés
Aucune alerte pour les problèmes CI/CD ou de dépendances

9. Réponse aux incidents et coordination avec les fournisseurs

Point d’attention de l’auditeur

Êtes-vous préparé aux incidents fournisseurs ?

Checklist

⬜ Les plans de réponse aux incidents incluent des scénarios fournisseurs
⬜ Les chemins d’escalade et de notification des fournisseurs sont définis
⬜ Capacité à révoquer rapidement l’accès des fournisseurs
⬜ Des simulations ou tests d’incidents sont réalisés
⬜ Les revues post-incident sont documentées

Signaux d’alerte typiques

Incidents fournisseurs traités au cas par cas
Aucun processus de coordination documenté

10. Rétention des preuves et auditabilité

Point d’attention de l’auditeur

Les preuves peuvent-elles être produites sur demande ?

Checklist

⬜ Les périodes de rétention des preuves sont définies
⬜ Les journaux CI/CD et enregistrements de sécurité sont conservés
⬜ La documentation des fournisseurs est archivée
⬜ Les preuves historiques peuvent être récupérées

Signaux d’alerte typiques

Périodes de rétention trop courtes
Preuves dispersées entre plusieurs systèmes

Questions finales d’évaluation de l’auditeur

Avant de clôturer un audit, les autorités de supervision se posent généralement les questions suivantes :

Les risques de la chaîne d’approvisionnement sont-ils clairement compris ?
Les contrôles sont-ils appliqués techniquement, et pas seulement documentés ?
Les preuves sont-elles fiables, complètes et récupérables ?
Le CI/CD est-il traité comme faisant partie de l’environnement réglementé ?

Si ces questions peuvent recevoir une réponse assurée, la préparation NIS2 de la chaîne d’approvisionnement est généralement considérée comme satisfaisante.

Ressources connexes

Pour un examen complet des exigences de sécurité de la chaîne d’approvisionnement NIS2 et leurs implications pour CI/CD et la gestion des fournisseurs, consultez NIS2 Supply Chain Security Deep Dive : ce que cela signifie vraiment pour CI/CD et les fournisseurs.

Ressources connexes pour les auditeurs

Glossaire — Définitions en langage clair des termes techniques
DORA Article 28 expliqué
Comparaison NIS2 vs DORA
Contrôles de sécurité CI/CD fondamentaux

Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.