{"id":1355,"date":"2026-03-25T16:58:37","date_gmt":"2026-03-25T15:58:37","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/soc-2-trust-service-criteria-mapped-to-pipeline-controls-2\/"},"modified":"2026-03-26T00:19:07","modified_gmt":"2026-03-25T23:19:07","slug":"soc-2-trust-service-criteria-mapped-to-pipeline-controls","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/soc-2-trust-service-criteria-mapped-to-pipeline-controls\/","title":{"rendered":"Crit\u00e8res SOC 2 Trust Service appliqu\u00e9s aux contr\u00f4les de pipeline"},"content":{"rendered":"

Introduction : pourquoi les pipelines CI\/CD rel\u00e8vent du p\u00e9rim\u00e8tre SOC 2<\/h2>\n

La livraison logicielle moderne repose sur les pipelines CI\/CD comme m\u00e9canisme central par lequel les changements de code passent du d\u00e9veloppement \u00e0 la production. Pour les organisations poursuivant une attestation SOC 2, ces pipelines ne sont pas simplement une infrastructure d’ing\u00e9nierie \u2014 ce sont des environnements de contr\u00f4le<\/strong> qui affectent directement l’int\u00e9grit\u00e9, la disponibilit\u00e9 et la confidentialit\u00e9 des services fournis aux clients.<\/p>\n

Les auditeurs SOC 2 reconnaissent de plus en plus que les pipelines CI\/CD repr\u00e9sentent un point de contr\u00f4le critique o\u00f9 les d\u00e9cisions d’acc\u00e8s sont appliqu\u00e9es, les changements sont autoris\u00e9s, les tests de s\u00e9curit\u00e9 sont effectu\u00e9s et l’int\u00e9grit\u00e9 du d\u00e9ploiement est \u00e9tablie. Si votre organisation livre des logiciels via des pipelines automatis\u00e9s, ces pipelines sont pleinement dans le p\u00e9rim\u00e8tre de votre engagement SOC 2.<\/p>\n

Cet article fournit un mapping complet entre les crit\u00e8res AICPA Trust Service et les contr\u00f4les sp\u00e9cifiques qui doivent \u00eatre impl\u00e9ment\u00e9s et d\u00e9montr\u00e9s dans les environnements CI\/CD.<\/p>\n

Mapping complet TSC vers les contr\u00f4les de pipeline<\/h2>\n

Le tableau suivant associe chaque crit\u00e8re Trust Service pertinent au contr\u00f4le CI\/CD correspondant et aux preuves qu’un auditeur s’attend \u00e0 examiner.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Crit\u00e8re TSC<\/th>\nDescription du crit\u00e8re<\/th>\nContr\u00f4le CI\/CD<\/th>\nPreuves requises<\/th>\n<\/tr>\n<\/thead>\n
CC6.1<\/td>\nS\u00e9curit\u00e9 de l’acc\u00e8s logique aux actifs prot\u00e9g\u00e9s<\/td>\nContr\u00f4le d’acc\u00e8s bas\u00e9 sur les r\u00f4les (RBAC) pour les syst\u00e8mes de pipeline, permissions des d\u00e9p\u00f4ts<\/td>\nExports de configuration RBAC, listes de contr\u00f4le d’acc\u00e8s, matrices de permissions<\/td>\n<\/tr>\n
CC6.2<\/td>\nIdentifiants d’acc\u00e8s g\u00e9r\u00e9s et authentifi\u00e9s<\/td>\nApplication du MFA, gouvernance des comptes de service, gestion des secrets<\/td>\nRegistres d’inscription MFA, journaux de rotation des secrets, rapports d’audit des identifiants<\/td>\n<\/tr>\n
CC6.3<\/td>\nAcc\u00e8s autoris\u00e9 selon le besoin m\u00e9tier<\/td>\nApplication du moindre privil\u00e8ge, acc\u00e8s juste-\u00e0-temps pour les permissions \u00e9lev\u00e9es<\/td>\nRegistres de demande\/approbation d’acc\u00e8s, revues d’acc\u00e8s trimestrielles, journaux d’escalade de privil\u00e8ges<\/td>\n<\/tr>\n
CC6.6<\/td>\nMesures de s\u00e9curit\u00e9 contre les menaces externes<\/td>\nSegmentation r\u00e9seau des environnements de build, isolation des runners, int\u00e9grit\u00e9 des artefacts<\/td>\nDiagrammes r\u00e9seau, r\u00e8gles de pare-feu, documentation de configuration des runners<\/td>\n<\/tr>\n
CC7.1<\/td>\nD\u00e9tection des changements de configuration<\/td>\nSurveillance de la configuration des pipelines, d\u00e9tection de d\u00e9rive, audit de l’infrastructure-as-code<\/td>\nJournaux de changements de configuration, rapports de d\u00e9tection de d\u00e9rive, pistes d’audit IaC<\/td>\n<\/tr>\n
CC7.2<\/td>\nSurveillance des anomalies et indicateurs de compromission<\/td>\nD\u00e9tection d’anomalies de pipeline, alertes sur des patterns de build inhabituels, surveillance des d\u00e9ploiements \u00e9chou\u00e9s<\/td>\nConfiguration des alertes, rapports de d\u00e9tection d’anomalies, tickets d’incidents issus des alertes<\/td>\n<\/tr>\n
CC7.3<\/td>\n\u00c9valuation des \u00e9v\u00e9nements d\u00e9tect\u00e9s<\/td>\nProcessus de triage des \u00e9v\u00e9nements de s\u00e9curit\u00e9 de pipeline, classification de s\u00e9v\u00e9rit\u00e9<\/td>\nRunbooks de r\u00e9ponse aux incidents, registres de triage, journaux de classification des \u00e9v\u00e9nements<\/td>\n<\/tr>\n
CC7.4<\/td>\nEx\u00e9cution de la r\u00e9ponse aux incidents<\/td>\nProc\u00e9dures de r\u00e9ponse aux incidents de pipeline, processus de rollback d’urgence<\/td>\nPlans de r\u00e9ponse aux incidents couvrant CI\/CD, revues post-incident, journaux d’ex\u00e9cution de rollback<\/td>\n<\/tr>\n
CC8.1<\/td>\nChangements autoris\u00e9s, con\u00e7us, d\u00e9velopp\u00e9s, configur\u00e9s, test\u00e9s et approuv\u00e9s<\/td>\nRevue de code obligatoire, workflows d’approbation, portes de d\u00e9ploiement, tests automatis\u00e9s<\/td>\nRegistres d’approbation des merge requests, journaux de passage\/\u00e9chec des portes, rapports d’ex\u00e9cution des tests<\/td>\n<\/tr>\n
CC9.1<\/td>\nIdentification et \u00e9valuation des risques<\/td>\n\u00c9valuations des risques des d\u00e9pendances tierces, mod\u00e9lisation des menaces de pipeline<\/td>\nRegistres des risques, inventaires de d\u00e9pendances, documents de mod\u00e9lisation des menaces<\/td>\n<\/tr>\n
CC9.2<\/td>\nActivit\u00e9s d’att\u00e9nuation des risques<\/td>\nAnalyse des d\u00e9pendances, SLA de rem\u00e9diation des vuln\u00e9rabilit\u00e9s, \u00e9valuations des fournisseurs<\/td>\nRapports d’analyse, d\u00e9lais de rem\u00e9diation, registres d’\u00e9valuation des fournisseurs<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

CC6 : contr\u00f4les d’acc\u00e8s logiques et physiques dans CI\/CD<\/h2>\n

Les contr\u00f4les d’acc\u00e8s au sein des environnements CI\/CD pr\u00e9sentent des d\u00e9fis uniques par rapport \u00e0 l’acc\u00e8s applicatif traditionnel. Les syst\u00e8mes de pipeline impliquent souvent plusieurs plateformes interconnect\u00e9es \u2014 d\u00e9p\u00f4ts de code source, syst\u00e8mes de build, registres d’artefacts, orchestrateurs de d\u00e9ploiement et fournisseurs d’infrastructure cloud.<\/p>\n

Exigences cl\u00e9s de contr\u00f4le<\/h3>\n

Contr\u00f4le d’acc\u00e8s bas\u00e9 sur les r\u00f4les (RBAC) :<\/strong> Chaque plateforme de pipeline doit appliquer un RBAC granulaire distinguant d\u00e9veloppeurs, relecteurs, approbateurs et administrateurs. Les auditeurs v\u00e9rifient que les r\u00f4les sont formellement d\u00e9finis, document\u00e9s et appliqu\u00e9s de mani\u00e8re coh\u00e9rente sur tous les composants de pipeline.<\/p>\n

Authentification multi-facteurs (MFA) :<\/strong> Tout acc\u00e8s humain aux syst\u00e8mes de pipeline doit exiger le MFA. Cela inclut l’acc\u00e8s aux d\u00e9p\u00f4ts, les consoles de syst\u00e8mes de build, les interfaces d’approbation de d\u00e9ploiement et les consoles de gestion d’infrastructure. Les auditeurs testeront sp\u00e9cifiquement les sc\u00e9narios de contournement du MFA et les exceptions.<\/p>\n

Moindre privil\u00e8ge :<\/strong> Les comptes de service de pipeline, les identifiants des runners et les tokens d’automatisation doivent fonctionner avec les permissions minimales n\u00e9cessaires. Les comptes de service trop permissifs repr\u00e9sentent l’un des constats les plus courants dans les audits CI\/CD.<\/p>\n

Revues d’acc\u00e8s :<\/strong> Les revues d’acc\u00e8s trimestrielles doivent couvrir tous les syst\u00e8mes de pipeline. Ces revues doivent valider que les employ\u00e9s ayant quitt\u00e9 l’entreprise ont \u00e9t\u00e9 d\u00e9-provisionn\u00e9s, que les attributions de r\u00f4les restent appropri\u00e9es et que les permissions des comptes de service n’ont pas d\u00e9pass\u00e9 leur port\u00e9e initiale.<\/p>\n

CC7 : op\u00e9rations syst\u00e8me \u2014 surveillance des pipelines et r\u00e9ponse aux incidents<\/h2>\n

La surveillance op\u00e9rationnelle des pipelines CI\/CD doit aller au-del\u00e0 des m\u00e9triques de disponibilit\u00e9 et de performance. SOC 2 exige que les organisations d\u00e9tectent, \u00e9valuent et r\u00e9pondent aux \u00e9v\u00e9nements susceptibles d’affecter la prestation de services.<\/p>\n

Exigences de surveillance des pipelines<\/h3>\n