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.
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.
Pour une checklist d’audit prête à l’emploi, consultez Checklist d’audit NIS2 pour la chaîne d’approvisionnement.
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.
