{"id":1359,"date":"2026-03-25T16:59:00","date_gmt":"2026-03-25T15:59:00","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/nis2-supply-chain-security-auditing-third-party-components-in-ci-cd-2\/"},"modified":"2026-07-07T10:47:10","modified_gmt":"2026-07-07T09:47:10","slug":"nis2-supply-chain-security-auditing-third-party-components-in-ci-cd","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/audit-evidence\/nis2-supply-chain-security-auditing-third-party-components-in-ci-cd\/","title":{"rendered":"S\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement NIS2 \u2014 Auditer les composants tiers dans le CI\/CD"},"content":{"rendered":"

NIS2 Article 21(2)(d) : exigences de s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement<\/h2>\n

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\n

Risques tiers dans les environnements CI\/CD<\/h2>\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\n

D\u00e9pendances open-source<\/h3>\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\n

Plateforme CI\/CD et outils SaaS<\/h3>\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\n

Runners de build partag\u00e9s et h\u00e9berg\u00e9s<\/h3>\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\n

Images de base et registres de conteneurs<\/h3>\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\n

SCA et SBOM comme outils de gouvernance de la cha\u00eene d’approvisionnement<\/h2>\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\n

Software Composition Analysis (SCA)<\/h3>\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

    \n
  • Inventaire des composants :<\/strong> Une liste compl\u00e8te de toutes les biblioth\u00e8ques tierces et leurs versions utilis\u00e9es dans chaque build<\/li>\n
  • Identification des vuln\u00e9rabilit\u00e9s :<\/strong> Mapping des composants par rapport aux bases de donn\u00e9es de vuln\u00e9rabilit\u00e9s connues<\/li>\n
  • Conformit\u00e9 des licences :<\/strong> Identification des obligations de licence pouvant cr\u00e9er un risque juridique ou op\u00e9rationnel<\/li>\n
  • Application des politiques :<\/strong> La capacit\u00e9 de bloquer les builds incluant des composants interdits ou \u00e0 haut risque<\/li>\n<\/ul>\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\n

    Software Bill of Materials (SBOM)<\/h3>\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

      \n
    • Transparence :<\/strong> Un enregistrement complet de ce qui est inclus dans chaque artefact d\u00e9ploy\u00e9<\/li>\n
    • Support \u00e0 la r\u00e9ponse aux incidents :<\/strong> La capacit\u00e9 de d\u00e9terminer rapidement si une vuln\u00e9rabilit\u00e9 nouvellement divulgu\u00e9e affecte un logiciel d\u00e9ploy\u00e9<\/li>\n
    • Preuve r\u00e9glementaire :<\/strong> Preuve d\u00e9montrable de la connaissance et de la gestion de la cha\u00eene d’approvisionnement<\/li>\n
    • Responsabilit\u00e9 des fournisseurs :<\/strong> Une base pour tenir les fournisseurs responsables des composants qu’ils fournissent<\/li>\n<\/ul>\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\n

      Cadre d’\u00e9valuation des fournisseurs pour les fournisseurs d’outils CI\/CD<\/h2>\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>\n\n

      Certifications et attestations de s\u00e9curit\u00e9<\/h3>\n
        \n
      • Le fournisseur d\u00e9tient-il des certifications pertinentes (ISO 27001, SOC 2 Type II) ?<\/li>\n
      • Les rapports d’audit sont-ils \u00e0 jour et disponibles pour examen ?<\/li>\n
      • Le fournisseur subit-il des tests d’intrusion r\u00e9guliers par des \u00e9valuateurs ind\u00e9pendants ?<\/li>\n<\/ul>\n\n

        Traitement des donn\u00e9es et isolation<\/h3>\n
          \n
        • Comment le fournisseur isole-t-il les donn\u00e9es clients et les environnements de build ?<\/li>\n
        • O\u00f9 les donn\u00e9es sont-elles stock\u00e9es, et cela respecte-t-il les exigences applicables de r\u00e9sidence des donn\u00e9es ?<\/li>\n
        • Quel chiffrement est appliqu\u00e9 aux donn\u00e9es au repos et en transit ?<\/li>\n<\/ul>\n\n

          Acc\u00e8s et authentification<\/h3>\n
            \n
          • Le fournisseur supporte-t-il et applique-t-il le MFA pour l’acc\u00e8s administratif ?<\/li>\n
          • Quel acc\u00e8s le personnel du fournisseur a-t-il aux environnements et donn\u00e9es clients ?<\/li>\n
          • Les \u00e9v\u00e9nements d’acc\u00e8s privil\u00e9gi\u00e9 sont-ils journalis\u00e9s et disponibles pour le client ?<\/li>\n<\/ul>\n\n

            Notification d’incidents<\/h3>\n
              \n
            • Quels sont les engagements et d\u00e9lais de notification d’incidents du fournisseur ?<\/li>\n
            • Les SLA contractuels s’alignent-ils avec les d\u00e9lais de signalement de l’article 23 de NIS2 ?<\/li>\n
            • Le fournisseur a-t-il d\u00e9montr\u00e9 la notification d’incidents en pratique ?<\/li>\n<\/ul>\n\n

              Transparence de la cha\u00eene d’approvisionnement<\/h3>\n
                \n
              • Le fournisseur divulgue-t-il ses propres d\u00e9pendances tierces et sous-traitants ?<\/li>\n
              • Quels contr\u00f4les le fournisseur applique-t-il \u00e0 sa propre cha\u00eene d’approvisionnement ?<\/li>\n
              • Le fournisseur peut-il fournir des SBOM pour ses produits ?<\/li>\n<\/ul>\n\n

                Mapping des risques, contr\u00f4les et preuves de la cha\u00eene d’approvisionnement<\/h2>\n\n\n\n\n
                Risque de la cha\u00eene d’approvisionnement<\/th>Contr\u00f4le<\/th>Preuves pour les auditeurs<\/th><\/tr>\n<\/thead>\n
                D\u00e9pendance open-source vuln\u00e9rable<\/strong><\/td>Analyse SCA obligatoire au moment du build avec blocage bas\u00e9 sur les politiques des vuln\u00e9rabilit\u00e9s critiques\/\u00e9lev\u00e9es<\/td>Rapports d’analyse SCA par build ; documentation de la politique de blocage ; registres d’exceptions\/d\u00e9rogations avec justification et dates d’expiration<\/td><\/tr>\n
                Injection de paquet malveillant<\/strong> (typosquatting, dependency confusion)<\/td>Registre de paquets approuv\u00e9 avec contr\u00f4les de namespace ; \u00e9pinglage des d\u00e9pendances et v\u00e9rification d’int\u00e9grit\u00e9<\/td>Configuration du registre approuv\u00e9 ; listes blanches de paquets ; journaux de v\u00e9rification d’int\u00e9grit\u00e9 (validation checksum\/signature)<\/td><\/tr>\n
                Image de base compromise<\/strong><\/td>Catalogue d’images de base approuv\u00e9es ; analyse d’image avant utilisation ; signature et v\u00e9rification d’image<\/td>Liste d’images approuv\u00e9es avec dates de revue ; rapports d’analyse d’images ; registres de v\u00e9rification de signature<\/td><\/tr>\n
                Violation du fournisseur de plateforme CI\/CD<\/strong><\/td>\u00c9valuation des risques fournisseur ; exigences contractuelles de s\u00e9curit\u00e9 ; planification de contingence pour la d\u00e9faillance du fournisseur<\/td>Rapports d’\u00e9valuation fournisseur (\u00e0 jour dans les 12 mois) ; contrats avec clauses de s\u00e9curit\u00e9 ; plans de continuit\u00e9 d’activit\u00e9 couvrant la perte de plateforme CI\/CD<\/td><\/tr>\n
                Contamination crois\u00e9e des runners partag\u00e9s<\/strong><\/td>Environnements de build d\u00e9di\u00e9s ou \u00e9ph\u00e9m\u00e8res ; politiques d’isolation des runners ; nettoyage post-build de l’environnement<\/td>Documentation de l’architecture de l’environnement de build ; attestations de configuration d’isolation ; journaux de v\u00e9rification de nettoyage<\/td><\/tr>\n
                Plugin ou int\u00e9gration CI\/CD compromis<\/strong><\/td>Processus d’approbation des plugins\/int\u00e9grations ; revue p\u00e9riodique des plugins install\u00e9s ; permissions de moindre privil\u00e8ge pour les int\u00e9grations<\/td>Registre des plugins approuv\u00e9s ; registres de revue des plugins ; matrices de permissions pour les int\u00e9grations<\/td><\/tr>\n
                Manque de tra\u00e7abilit\u00e9 des composants<\/strong><\/td>G\u00e9n\u00e9ration de SBOM pour chaque mise en production ; stockage et capacit\u00e9 d’interrogation des SBOM<\/td>SBOM pour les mises en production r\u00e9centes ; preuve de capacit\u00e9 d’interrogation SBOM (ex. r\u00e9ponse \u00e0 une requ\u00eate de vuln\u00e9rabilit\u00e9 test) ; conformit\u00e9 de la politique de r\u00e9tention<\/td><\/tr>\n
                Verrouillage fournisseur emp\u00eachant la migration s\u00e9curitaire<\/strong><\/td>\u00c9valuation de la strat\u00e9gie multi-fournisseurs ; \u00e9valuation de la portabilit\u00e9 des donn\u00e9es ; planification de sortie<\/td>Analyse de d\u00e9pendance fournisseur ; documentation de capacit\u00e9 d’export de donn\u00e9es ; plan de sortie<\/td><\/tr>\n<\/tbody>\n<\/table>\n\n

                Signaux d’alerte que les auditeurs doivent surveiller<\/h2>\n

                Lors d’une \u00e9valuation de la s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement des environnements CI\/CD, les constats suivants doivent susciter une pr\u00e9occupation imm\u00e9diate :<\/p>\n

                  \n
                • Pas de politique de gouvernance des d\u00e9pendances :<\/strong> L’organisation n’a pas de politique document\u00e9e r\u00e9gissant l’utilisation de composants tiers dans les builds. Cela sugg\u00e8re une lacune fondamentale dans la sensibilisation \u00e0 la cha\u00eene d’approvisionnement.<\/li>\n
                • L’analyse SCA est uniquement consultative :<\/strong> Les analyses de vuln\u00e9rabilit\u00e9s s’ex\u00e9cutent mais ne bloquent pas les d\u00e9ploiements. Les d\u00e9veloppeurs peuvent (et le font) d\u00e9ployer avec des vuln\u00e9rabilit\u00e9s critiques connues. Recherchez des preuves de builds poursuivis malgr\u00e9 des constats de s\u00e9v\u00e9rit\u00e9 \u00e9lev\u00e9e.<\/li>\n
                • Pas de g\u00e9n\u00e9ration de SBOM :<\/strong> L’organisation ne peut pas produire d’inventaire de composants pour ses logiciels d\u00e9ploy\u00e9s. Il est alors impossible d’\u00e9valuer l’exposition aux vuln\u00e9rabilit\u00e9s nouvellement divulgu\u00e9es.<\/li>\n
                • \u00c9valuations fournisseurs p\u00e9rim\u00e9es :<\/strong> Les fournisseurs d’outils CI\/CD ont \u00e9t\u00e9 \u00e9valu\u00e9s une seule fois (peut-\u00eatre lors de l’approvisionnement) mais n’ont pas \u00e9t\u00e9 r\u00e9\u00e9valu\u00e9s. Recherchez des dates d’\u00e9valuation de plus de 12 mois.<\/li>\n
                • Acc\u00e8s non restreint aux registres publics :<\/strong> Les builds extraient les d\u00e9pendances directement des registres publics sans registre approuv\u00e9 interm\u00e9diaire ni v\u00e9rification d’int\u00e9grit\u00e9. C’est une exposition directe aux attaques de dependency confusion et de typosquatting.<\/li>\n
                • Pas de gouvernance des images de base :<\/strong> Les \u00e9quipes utilisent des images de base arbitraires provenant de sources publiques sans analyse, approbation ou \u00e9pinglage de version. Chaque image non v\u00e9rifi\u00e9e est un point d’entr\u00e9e potentiel pour une compromission.<\/li>\n
                • Runners partag\u00e9s sans preuve d’isolation :<\/strong> L’organisation utilise une infrastructure de build partag\u00e9e mais ne peut pas d\u00e9montrer que les builds sont isol\u00e9s les uns des autres.<\/li>\n
                • Exigences de s\u00e9curit\u00e9 contractuelles manquantes :<\/strong> Les accords avec les fournisseurs d’outils CI\/CD ne contiennent aucune clause de s\u00e9curit\u00e9, aucune obligation de notification d’incident et aucun droit d’audit.<\/li>\n
                • Pas de processus de gestion des exceptions :<\/strong> Lorsque les contr\u00f4les de la cha\u00eene d’approvisionnement sont contourn\u00e9s (ex. une d\u00e9pendance vuln\u00e9rable est accept\u00e9e), il n’y a pas de processus d’exception formel avec justification document\u00e9e, acceptation du risque et date d’expiration.<\/li>\n
                • Plugins et int\u00e9grations sans revue :<\/strong> Les plateformes CI\/CD ont de nombreux plugins tiers install\u00e9s sans preuve de revue de s\u00e9curit\u00e9 ou de processus d’approbation.<\/li>\n<\/ul>\n\n\n

                  Checklist d’audit NIS2 pour la cha\u00eene d’approvisionnement<\/h2>\n\n\n\n

                  Les sections ci-dessus d\u00e9crivent ce que les auditeurs recherchent et pourquoi. La checklist ci-dessous transforme ces attentes en une revue structur\u00e9e en dix parties qui refl\u00e8te la fa\u00e7on dont les exigences NIS2 en mati\u00e8re de cha\u00eene d’approvisionnement sont r\u00e9ellement examin\u00e9es par les auditeurs et les autorit\u00e9s de supervision<\/strong> — en mettant l’accent sur la gouvernance, l’application technique et les preuves plut\u00f4t que sur des d\u00e9clarations de principe de haut niveau. Utilisez-la pour \u00e9valuer votre pr\u00e9paration avant un audit, ou pour guider la pr\u00e9paration des preuves une fois la supervision engag\u00e9e.<\/p>\n\n\n\n

                  1. P\u00e9rim\u00e8tre et identification des fournisseurs<\/strong><\/h3>\n\n\n\n

                  Point d’attention de l’auditeur<\/strong><\/h4>\n\n\n\n
                  \n

                  Tous les fournisseurs pertinents sont-ils identifi\u00e9s et inclus dans le p\u00e9rim\u00e8tre ?<\/p>\n<\/blockquote>\n\n\n\n

                  Checklist<\/strong><\/h4>\n\n\n\n