L’article 21(2)(d) de NIS2 exige des entit\u00e9s essentielles et importantes qu’elles traitent la s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement<\/strong>, y compris les aspects li\u00e9s \u00e0 la s\u00e9curit\u00e9 concernant les relations entre chaque entit\u00e9 et ses fournisseurs directs ou prestataires de services. Pour les organisations qui construisent et d\u00e9ploient des logiciels via des pipelines CI\/CD, cette exigence a des implications consid\u00e9rables.<\/p>\n Le pipeline CI\/CD moderne est, par nature, une cha\u00eene d’approvisionnement. Chaque build incorpore des biblioth\u00e8ques tierces, des images de base, des services externes et des outils provenant de multiples fournisseurs. Un seul composant compromis n’importe o\u00f9 dans cette cha\u00eene peut se propager \u00e0 travers les pipelines automatis\u00e9s vers les environnements de production en quelques minutes. Les auditeurs doivent donc \u00e9valuer non seulement les contr\u00f4les propres de l’organisation, mais aussi le cadre de gouvernance entourant chaque \u00e9l\u00e9ment tiers qui entre dans le pipeline de livraison.<\/p>\n Comprendre les cat\u00e9gories de risques tiers dans CI\/CD est essentiel pour d\u00e9limiter le p\u00e9rim\u00e8tre d’un audit. Les domaines suivants repr\u00e9sentent la surface de risque principale :<\/p>\n La plupart des applications modernes int\u00e8grent des dizaines \u00e0 des centaines de biblioth\u00e8ques open-source. Chaque d\u00e9pendance \u2014 et ses d\u00e9pendances transitives \u2014 repr\u00e9sente une vuln\u00e9rabilit\u00e9 ou un vecteur d’attaque potentiel. Les risques incluent les vuln\u00e9rabilit\u00e9s connues dans les paquets obsol\u00e8tes, les paquets malveillants publi\u00e9s sous des noms similaires (typosquatting) et les comptes de mainteneurs compromis.<\/p>\n Les organisations s’appuient fr\u00e9quemment sur des plateformes SaaS tierces pour le contr\u00f4le de source, l’ex\u00e9cution de builds, le stockage d’artefacts et l’orchestration de d\u00e9ploiement. Ces plateformes ont un acc\u00e8s privil\u00e9gi\u00e9 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.<\/p>\n Les environnements de build partag\u00e9s entre projets ou h\u00e9berg\u00e9s par des tiers introduisent des risques de contamination crois\u00e9e, de fuite de donn\u00e9es et d’isolation insuffisante. Si un runner de build est compromis, chaque pipeline qui l’utilise est potentiellement affect\u00e9.<\/p>\n Les d\u00e9ploiements bas\u00e9s sur des conteneurs d\u00e9pendent d’images de base souvent sourc\u00e9es depuis des registres publics. Ces images peuvent contenir des vuln\u00e9rabilit\u00e9s, des composants inutiles qui \u00e9largissent la surface d’attaque, ou dans de rares cas, du contenu d\u00e9lib\u00e9r\u00e9ment malveillant.<\/p>\n Deux capacit\u00e9s cl\u00e9s soutiennent la gouvernance de la cha\u00eene d’approvisionnement dans les environnements CI\/CD. Les auditeurs doivent comprendre ce que chacune fournit et v\u00e9rifier que l’organisation les utilise efficacement.<\/p>\n Le SCA fournit une visibilit\u00e9 sur les composants tiers pr\u00e9sents dans une application. Du point de vue de la gouvernance, le SCA apporte :<\/p>\n Les auditeurs doivent v\u00e9rifier que le SCA est int\u00e9gr\u00e9 dans le pipeline comme une porte obligatoire \u2014 et non une \u00e9tape consultative optionnelle \u2014 et que les violations de politique entra\u00eenent des d\u00e9ploiements bloqu\u00e9s avec des processus d’exception document\u00e9s.<\/p>\n Un SBOM est un inventaire formel et lisible par machine de tous les composants d’un artefact logiciel. Pour la gouvernance de la cha\u00eene d’approvisionnement, les SBOM fournissent :<\/p>\n Les auditeurs doivent confirmer que les SBOM sont g\u00e9n\u00e9r\u00e9s pour chaque mise en production, stock\u00e9s avec des p\u00e9riodes de r\u00e9tention appropri\u00e9es, et que l’organisation peut les interroger pour identifier les syst\u00e8mes affect\u00e9s lorsque de nouvelles vuln\u00e9rabilit\u00e9s sont divulgu\u00e9es.<\/p>\n Les organisations doivent \u00e9valuer la posture de s\u00e9curit\u00e9 de leurs fournisseurs d’outils CI\/CD avec la m\u00eame rigueur appliqu\u00e9e \u00e0 tout prestataire de services critique. Le cadre suivant d\u00e9crit les domaines cl\u00e9s d’\u00e9valuation :<\/p>\nRisques tiers dans les environnements CI\/CD<\/h2>\n
D\u00e9pendances open-source<\/h3>\n
Plateforme CI\/CD et outils SaaS<\/h3>\n
Runners de build partag\u00e9s et h\u00e9berg\u00e9s<\/h3>\n
Images de base et registres de conteneurs<\/h3>\n
SCA et SBOM comme outils de gouvernance de la cha\u00eene d’approvisionnement<\/h2>\n
Software Composition Analysis (SCA)<\/h3>\n
\n
Software Bill of Materials (SBOM)<\/h3>\n
\n
Cadre d’\u00e9valuation des fournisseurs pour les fournisseurs d’outils CI\/CD<\/h2>\n
Certifications et attestations de s\u00e9curit\u00e9<\/h3>\n
\n
Traitement des donn\u00e9es et isolation<\/h3>\n
\n
Acc\u00e8s et authentification<\/h3>\n
\n
Notification d’incidents<\/h3>\n
\n
Transparence de la cha\u00eene d’approvisionnement<\/h3>\n
\n
Mapping des risques, contr\u00f4les et preuves de la cha\u00eene d’approvisionnement<\/h2>\n