{"id":1395,"date":"2026-03-25T17:00:36","date_gmt":"2026-03-25T16:00:36","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/soc-2-readiness-assessment-ci-cd-specific-checklist-2\/"},"modified":"2026-03-26T00:21:17","modified_gmt":"2026-03-25T23:21:17","slug":"soc-2-readiness-assessment-ci-cd-specific-checklist","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/audit-evidence\/soc-2-readiness-assessment-ci-cd-specific-checklist\/","title":{"rendered":"\u00c9valuation de pr\u00e9paration SOC 2 \u2014 Checklist sp\u00e9cifique CI\/CD"},"content":{"rendered":"

Objectif de cette \u00e9valuation de pr\u00e9paration<\/h2>\n

Cette checklist d’auto-\u00e9valuation est con\u00e7ue pour les organisations se pr\u00e9parant \u00e0 un examen SOC 2 Type II incluant les pipelines CI\/CD dans le p\u00e9rim\u00e8tre d’audit. Utilisez-la pour identifier les lacunes de contr\u00f4le, prioriser les efforts de rem\u00e9diation et \u00e9tablir la confiance que votre environnement de pipeline r\u00e9sistera \u00e0 l’examen des auditeurs.<\/p>\n

Pour chaque \u00e9l\u00e9ment de la checklist, \u00e9valuez votre \u00e9tat actuel comme Oui<\/strong> (enti\u00e8rement impl\u00e9ment\u00e9 et document\u00e9), Partiel<\/strong> (partiellement impl\u00e9ment\u00e9 ou manquant de preuves), ou Non<\/strong> (non impl\u00e9ment\u00e9). Les \u00e9l\u00e9ments \u00e9valu\u00e9s comme Partiel ou Non n\u00e9cessitent une rem\u00e9diation avant le d\u00e9but de la p\u00e9riode d’audit.<\/p>\n

CC6 : checklist des contr\u00f4les d’acc\u00e8s<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
#<\/th>\n\u00c9l\u00e9ment de contr\u00f4le<\/th>\nStatut (O\/P\/N)<\/th>\nPreuves requises<\/th>\nOrientations de rem\u00e9diation<\/th>\n<\/tr>\n<\/thead>\n
6.1<\/td>\nLe RBAC est configur\u00e9 sur toutes les plateformes de pipeline (d\u00e9p\u00f4t, syst\u00e8me de build, registre d’artefacts, outils de d\u00e9ploiement)<\/td>\n<\/td>\nExports de configuration RBAC, document de d\u00e9finition des r\u00f4les<\/td>\nD\u00e9finir les r\u00f4les standard (d\u00e9veloppeur, relecteur, approbateur, admin) et les mapper au mod\u00e8le de permissions de chaque plateforme<\/td>\n<\/tr>\n
6.2<\/td>\nLe MFA est appliqu\u00e9 pour tous les comptes humains acc\u00e9dant aux syst\u00e8mes de pipeline<\/td>\n<\/td>\nConfiguration de politique MFA, rapports d’inscription, journal d’exceptions<\/td>\nActiver le MFA \u00e0 l’\u00e9chelle de l’organisation ; documenter toute exception technique avec des contr\u00f4les compensatoires<\/td>\n<\/tr>\n
6.3<\/td>\nLes comptes de service suivent le principe de moindre privil\u00e8ge avec justification document\u00e9e pour chaque permission<\/td>\n<\/td>\nInventaire des comptes de service, matrice de justification des permissions<\/td>\nAuditer tous les comptes de service ; supprimer les permissions inutiles ; documenter la justification m\u00e9tier des permissions restantes<\/td>\n<\/tr>\n
6.4<\/td>\nDes revues d’acc\u00e8s trimestrielles sont planifi\u00e9es et couvrent tous les syst\u00e8mes de pipeline<\/td>\n<\/td>\nCalendrier de revue, registres de revues achev\u00e9es, preuves de rem\u00e9diation<\/td>\n\u00c9tablir des \u00e9v\u00e9nements r\u00e9currents au calendrier ; assigner des responsables de revue ; cr\u00e9er un mod\u00e8le de revue standard<\/td>\n<\/tr>\n
6.5<\/td>\nLes proc\u00e9dures d’int\u00e9gration\/d\u00e9part incluent le provisionnement et le d\u00e9-provisionnement des acc\u00e8s aux syst\u00e8mes de pipeline<\/td>\n<\/td>\nDocumentation d’int\u00e9gration RH, checklists de d\u00e9-provisionnement, registres de d\u00e9lais<\/td>\nAjouter les syst\u00e8mes de pipeline aux checklists d’int\u00e9gration\/d\u00e9part IT ; automatiser dans la mesure du possible<\/td>\n<\/tr>\n
6.6<\/td>\nLes proc\u00e9dures d’acc\u00e8s d’urgence et de break-glass sont document\u00e9es et exigent une revue post-utilisation<\/td>\n<\/td>\nDocument de proc\u00e9dure d’acc\u00e8s d’urgence, journaux d’utilisation, registres de revue post-utilisation<\/td>\nDocumenter la proc\u00e9dure d’acc\u00e8s d’urgence ; impl\u00e9menter des alertes sur l’utilisation de l’acc\u00e8s d’urgence<\/td>\n<\/tr>\n
6.7<\/td>\nLes secrets et identifiants sont g\u00e9r\u00e9s par une solution d\u00e9di\u00e9e de gestion des secrets (non cod\u00e9s en dur)<\/td>\n<\/td>\nConfiguration de l’outil de gestion des secrets, r\u00e9sultats d’analyse montrant l’absence de secrets cod\u00e9s en dur<\/td>\nImpl\u00e9menter un outil de gestion des secrets ; ex\u00e9cuter une analyse de secrets sur tous les d\u00e9p\u00f4ts<\/td>\n<\/tr>\n
6.8<\/td>\nL’acc\u00e8s r\u00e9seau \u00e0 l’infrastructure de pipeline est restreint aux r\u00e9seaux et au personnel autoris\u00e9s<\/td>\n<\/td>\nDocumentation de configuration r\u00e9seau, r\u00e8gles de pare-feu, configuration VPN\/zero-trust<\/td>\nImpl\u00e9menter les restrictions r\u00e9seau ; documenter les chemins d’acc\u00e8s autoris\u00e9s<\/td>\n<\/tr>\n
6.9<\/td>\nL’acc\u00e8s des runners\/agents de pipeline est isol\u00e9 et ne peut acc\u00e9der aux ressources au-del\u00e0 de leur port\u00e9e d\u00e9finie<\/td>\n<\/td>\nConfiguration des runners, documentation d’isolation, preuves de segmentation r\u00e9seau<\/td>\nConfigurer l’isolation des runners ; impl\u00e9menter la segmentation r\u00e9seau pour les environnements de build<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

CC7 : checklist des op\u00e9rations syst\u00e8me<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
#<\/th>\n\u00c9l\u00e9ment de contr\u00f4le<\/th>\nStatut (O\/P\/N)<\/th>\nPreuves requises<\/th>\nOrientations de rem\u00e9diation<\/th>\n<\/tr>\n<\/thead>\n
7.1<\/td>\nLes changements de configuration de pipeline sont journalis\u00e9s et surveill\u00e9s avec des alertes pour les modifications non autoris\u00e9es<\/td>\n<\/td>\nConfiguration de surveillance, r\u00e8gles d’alerte, exemples de notifications d’alerte<\/td>\nImpl\u00e9menter la surveillance des changements de configuration ; configurer les alertes vers l’\u00e9quipe s\u00e9curit\u00e9<\/td>\n<\/tr>\n
7.2<\/td>\nLa d\u00e9tection d’anomalies est en place pour l’activit\u00e9 inhabituelle de pipeline (builds hors heures, patterns de d\u00e9ploiement inhabituels)<\/td>\n<\/td>\nR\u00e8gles de d\u00e9tection d’anomalies, documentation de r\u00e9f\u00e9rence, historique des alertes<\/td>\nD\u00e9finir les r\u00e9f\u00e9rences de comportement normal du pipeline ; configurer les alertes d’anomalies<\/td>\n<\/tr>\n
7.3<\/td>\nLes incidents de pipeline sont int\u00e9gr\u00e9s au programme de r\u00e9ponse aux incidents de l’organisation<\/td>\n<\/td>\nPlan de r\u00e9ponse aux incidents couvrant CI\/CD, crit\u00e8res de classification des incidents, proc\u00e9dures d’escalade<\/td>\nMettre \u00e0 jour le plan de r\u00e9ponse aux incidents pour inclure les sc\u00e9narios CI\/CD ; former l’\u00e9quipe de r\u00e9ponse aux incidents sp\u00e9cifiques au pipeline<\/td>\n<\/tr>\n
7.4<\/td>\nLa capacit\u00e9 de l’infrastructure de pipeline est surveill\u00e9e et g\u00e9r\u00e9e pour pr\u00e9venir la d\u00e9gradation<\/td>\n<\/td>\nTableaux de bord de surveillance de capacit\u00e9, politiques de mise \u00e0 l’\u00e9chelle, documents de planification de capacit\u00e9<\/td>\nImpl\u00e9menter la surveillance de capacit\u00e9 ; \u00e9tablir les seuils et proc\u00e9dures de mise \u00e0 l’\u00e9chelle<\/td>\n<\/tr>\n
7.5<\/td>\nDes proc\u00e9dures de sauvegarde et de r\u00e9cup\u00e9ration existent pour la configuration et l’infrastructure de pipeline<\/td>\n<\/td>\nCalendriers de sauvegarde, proc\u00e9dures de r\u00e9cup\u00e9ration, r\u00e9sultats de tests de r\u00e9cup\u00e9ration<\/td>\nImpl\u00e9menter les sauvegardes de configuration de pipeline ; documenter et tester les proc\u00e9dures de r\u00e9cup\u00e9ration<\/td>\n<\/tr>\n
7.6<\/td>\nLa journalisation est centralis\u00e9e avec des p\u00e9riodes de r\u00e9tention d\u00e9finies r\u00e9pondant aux exigences d’audit<\/td>\n<\/td>\nConfiguration d’agr\u00e9gation de journaux, documentation de politique de r\u00e9tention, v\u00e9rification du stockage<\/td>\nCentraliser les journaux de pipeline ; configurer la r\u00e9tention pour couvrir la p\u00e9riode d’audit plus une marge<\/td>\n<\/tr>\n
7.7<\/td>\nLes alertes d’\u00e9v\u00e9nements de s\u00e9curit\u00e9 ont des proc\u00e9dures de r\u00e9ponse d\u00e9finies et des responsables assign\u00e9s<\/td>\n<\/td>\nPlaybooks de r\u00e9ponse aux alertes, affectations de responsables, SLA de temps de r\u00e9ponse<\/td>\nCr\u00e9er des playbooks de r\u00e9ponse pour chaque type d’alerte ; assigner et former les responsables<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

CC8 : checklist de gestion des changements<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
#<\/th>\n\u00c9l\u00e9ment de contr\u00f4le<\/th>\nStatut (O\/P\/N)<\/th>\nPreuves requises<\/th>\nOrientations de rem\u00e9diation<\/th>\n<\/tr>\n<\/thead>\n
8.1<\/td>\nTous les changements de production n\u00e9cessitent une revue de code par les pairs par un relecteur qualifi\u00e9 qui n’est pas l’auteur<\/td>\n<\/td>\nR\u00e8gles de protection de branche, param\u00e8tres de merge request, exemples de registres de revue<\/td>\nConfigurer la protection de branche ; appliquer les exigences minimales de relecteur<\/td>\n<\/tr>\n
8.2<\/td>\nUne approbation formelle est requise avant le d\u00e9ploiement en production, avec approbation document\u00e9e et attribu\u00e9e<\/td>\n<\/td>\nConfiguration d’approbation de d\u00e9ploiement, journaux d’approbation avec horodatages et identit\u00e9 de l’approbateur<\/td>\nImpl\u00e9menter les portes d’approbation de d\u00e9ploiement ; s’assurer que les approbations sont journalis\u00e9es avec attribution<\/td>\n<\/tr>\n
8.3<\/td>\nLa s\u00e9paration des fonctions est appliqu\u00e9e \u2014 l’auteur ne peut pas approuver ou d\u00e9ployer ses propres changements<\/td>\n<\/td>\nConfiguration d’application de la s\u00e9paration des fonctions, rapports de validation montrant l’absence d’auto-approbations<\/td>\nConfigurer l’application technique emp\u00eachant l’auto-approbation ; ex\u00e9cuter des rapports de validation<\/td>\n<\/tr>\n
8.4<\/td>\nL’analyse de s\u00e9curit\u00e9 automatis\u00e9e (SAST, SCA, d\u00e9tection de secrets) s’ex\u00e9cute sur chaque changement avec des seuils d\u00e9finis<\/td>\n<\/td>\nConfiguration de pipeline montrant les \u00e9tapes d’analyse, param\u00e8tres de seuils, journaux d’application des portes<\/td>\nInt\u00e9grer les outils d’analyse de s\u00e9curit\u00e9 ; d\u00e9finir des seuils bas\u00e9s sur la s\u00e9v\u00e9rit\u00e9 ; configurer les portes de blocage<\/td>\n<\/tr>\n
8.5<\/td>\nLes portes de tests automatis\u00e9s emp\u00eachent le d\u00e9ploiement lorsque les crit\u00e8res qualit\u00e9 ne sont pas remplis<\/td>\n<\/td>\nConfiguration des portes de test, journaux de passage\/\u00e9chec, rapports de couverture de tests<\/td>\nD\u00e9finir les crit\u00e8res qualit\u00e9 minimaux ; configurer l’application automatis\u00e9e<\/td>\n<\/tr>\n
8.6<\/td>\nLes proc\u00e9dures de rollback sont document\u00e9es, test\u00e9es et peuvent \u00eatre ex\u00e9cut\u00e9es dans les d\u00e9lais d\u00e9finis<\/td>\n<\/td>\nDocumentation des proc\u00e9dures de rollback, registres de tests, mesures de temps d’ex\u00e9cution<\/td>\nDocumenter les proc\u00e9dures de rollback ; planifier et mener des tests de rollback<\/td>\n<\/tr>\n
8.7<\/td>\nLes proc\u00e9dures de changements d’urgence sont document\u00e9es avec des contr\u00f4les renforc\u00e9s (revue post-impl\u00e9mentation, approbation acc\u00e9l\u00e9r\u00e9e)<\/td>\n<\/td>\nDocument de proc\u00e9dure de changement d’urgence, journal des changements d’urgence, registres de revue post-impl\u00e9mentation<\/td>\nD\u00e9finir la proc\u00e9dure de changement d’urgence ; impl\u00e9menter le suivi et la revue post-impl\u00e9mentation obligatoire<\/td>\n<\/tr>\n
8.8<\/td>\nLa s\u00e9paration des environnements emp\u00eache les changements de d\u00e9veloppement\/test d’affecter directement la production<\/td>\n<\/td>\nDocumentation de l’architecture des environnements, restrictions d’acc\u00e8s entre environnements<\/td>\nImpl\u00e9menter la s\u00e9paration des environnements ; restreindre l’acc\u00e8s production \u00e0 l’automatisation de d\u00e9ploiement<\/td>\n<\/tr>\n
8.9<\/td>\nLes registres de changements fournissent une tra\u00e7abilit\u00e9 compl\u00e8te de l’exigence au d\u00e9ploiement en production<\/td>\n<\/td>\nExemples de registres de changements montrant la tra\u00e7abilit\u00e9 de bout en bout, configuration de liaison des outils<\/td>\nConfigurer la liaison ticket-d\u00e9ploiement ; s’assurer que tous les changements r\u00e9f\u00e9rencent un \u00e9l\u00e9ment de travail suivi<\/td>\n<\/tr>\n
8.10<\/td>\nLes changements pipeline-as-code sont soumis au m\u00eame processus de revue et d’approbation que les changements applicatifs<\/td>\n<\/td>\nProtection de branche sur les fichiers de configuration de pipeline, registres de revue des changements de pipeline<\/td>\n\u00c9tendre la protection de branche aux fichiers de d\u00e9finition de pipeline ; traiter comme des changements de production<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

CC9 : checklist d’att\u00e9nuation des risques<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
#<\/th>\n\u00c9l\u00e9ment de contr\u00f4le<\/th>\nStatut (O\/P\/N)<\/th>\nPreuves requises<\/th>\nOrientations de rem\u00e9diation<\/th>\n<\/tr>\n<\/thead>\n
9.1<\/td>\nUn inventaire complet des composants tiers et d\u00e9pendances consomm\u00e9s par le pipeline existe<\/td>\n<\/td>\nSoftware Bill of Materials (SBOM), rapports d’inventaire des d\u00e9pendances<\/td>\nImpl\u00e9menter la g\u00e9n\u00e9ration de SBOM ; ex\u00e9cuter l’inventaire des d\u00e9pendances sur tous les projets<\/td>\n<\/tr>\n
9.2<\/td>\nL’analyse automatis\u00e9e des d\u00e9pendances identifie les vuln\u00e9rabilit\u00e9s connues avec des SLA de rem\u00e9diation d\u00e9finis<\/td>\n<\/td>\nConfiguration d’analyse, rapports de vuln\u00e9rabilit\u00e9s, documentation des SLA, suivi de rem\u00e9diation<\/td>\nImpl\u00e9menter l’analyse des d\u00e9pendances ; d\u00e9finir des SLA de rem\u00e9diation bas\u00e9s sur la s\u00e9v\u00e9rit\u00e9<\/td>\n<\/tr>\n
9.3<\/td>\nLes fournisseurs SaaS de pipeline ont \u00e9t\u00e9 \u00e9valu\u00e9s pour la s\u00e9curit\u00e9 et leurs rapports SOC 2 examin\u00e9s<\/td>\n<\/td>\nRegistres d’\u00e9valuation fournisseur, revues de rapports SOC 2, documentation d’acceptation des risques<\/td>\nDemander les rapports SOC 2 de tous les fournisseurs de pipeline ; mener et documenter les \u00e9valuations<\/td>\n<\/tr>\n
9.4<\/td>\nLes risques d’infrastructure partag\u00e9e (runners partag\u00e9s, environnements de build multi-locataires) sont \u00e9valu\u00e9s et att\u00e9nu\u00e9s<\/td>\n<\/td>\nDocumentation d’\u00e9valuation des risques, contr\u00f4les d’att\u00e9nuation, v\u00e9rification d’isolation<\/td>\n\u00c9valuer les risques d’infrastructure partag\u00e9e ; impl\u00e9menter des runners d\u00e9di\u00e9s si le risque le justifie<\/td>\n<\/tr>\n
9.5<\/td>\nLa conformit\u00e9 des licences pour les composants open-source est surveill\u00e9e et g\u00e9r\u00e9e<\/td>\n<\/td>\nConfiguration d’analyse de licences, rapports de conformit\u00e9, liste de licences approuv\u00e9es<\/td>\nImpl\u00e9menter l’analyse de licences ; d\u00e9finir la liste de licences approuv\u00e9es ; \u00e9tablir un processus de revue pour les exceptions<\/td>\n<\/tr>\n
9.6<\/td>\nLes vecteurs d’attaque de la cha\u00eene d’approvisionnement (dependency confusion, paquets compromis) sont \u00e9valu\u00e9s avec des contr\u00f4les pr\u00e9ventifs<\/td>\n<\/td>\nDocumentation d’\u00e9valuation des menaces, configuration de registre priv\u00e9, param\u00e8tres de v\u00e9rification de paquets<\/td>\nImpl\u00e9menter des registres priv\u00e9s ou des proxys ; configurer la v\u00e9rification de signature des paquets<\/td>\n<\/tr>\n
9.7<\/td>\nL’acc\u00e8s des int\u00e9grations tierces (webhooks, tokens API, applications OAuth) est inventori\u00e9 et revu p\u00e9riodiquement<\/td>\n<\/td>\nInventaire des int\u00e9grations, documentation des port\u00e9es d’acc\u00e8s, registres de revue p\u00e9riodique<\/td>\nInventorier toutes les int\u00e9grations ; documenter les port\u00e9es d’acc\u00e8s ; planifier des revues p\u00e9riodiques<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Analyse des lacunes : comment prioriser la rem\u00e9diation<\/h2>\n

Apr\u00e8s avoir compl\u00e9t\u00e9 l’\u00e9valuation, cat\u00e9gorisez les constats en utilisant le cadre de priorit\u00e9 suivant :<\/p>\n\n\n\n\n\n\n\n\n
Priorit\u00e9<\/th>\nCrit\u00e8res<\/th>\nD\u00e9lai de rem\u00e9diation<\/th>\nExemples<\/th>\n<\/tr>\n<\/thead>\n
Critique<\/td>\nContr\u00f4le absent ; affecte directement l’opinion d’audit<\/td>\nImm\u00e9diat (dans les 2 semaines)<\/td>\nPas d’application d’approbation, pas de revues d’acc\u00e8s, pas de journalisation<\/td>\n<\/tr>\n
\u00c9lev\u00e9<\/td>\nContr\u00f4le partiellement impl\u00e9ment\u00e9 ; lacunes dans les preuves<\/td>\nDans les 30 jours<\/td>\nMFA non universel, revues incompl\u00e8tes, certains syst\u00e8mes exclus<\/td>\n<\/tr>\n
Moyen<\/td>\nContr\u00f4le existant mais qualit\u00e9 des preuves insuffisante<\/td>\nDans les 60 jours<\/td>\nPreuves manuelles, documentation incompl\u00e8te, processus informels<\/td>\n<\/tr>\n
Faible<\/td>\nOpportunit\u00e9 d’am\u00e9lioration du contr\u00f4le ; non critique pour l’audit<\/td>\nDans les 90 jours<\/td>\nAm\u00e9liorations d’automatisation, surveillance suppl\u00e9mentaire, rapports am\u00e9lior\u00e9s<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Calendrier de pr\u00e9paration recommand\u00e9 (6 mois avant l’audit)<\/h2>\n\n\n\n\n\n\n\n\n\n\n
P\u00e9riode<\/th>\nActivit\u00e9<\/th>\nLivrable<\/th>\n<\/tr>\n<\/thead>\n
Mois 1<\/td>\nCompl\u00e9ter cette \u00e9valuation de pr\u00e9paration ; identifier toutes les lacunes<\/td>\nChecklist compl\u00e9t\u00e9e avec analyse des lacunes et plan de rem\u00e9diation prioris\u00e9<\/td>\n<\/tr>\n
Mois 2<\/td>\nRem\u00e9dier les lacunes de priorit\u00e9 Critique et \u00c9lev\u00e9e<\/td>\nImpl\u00e9mentations de contr\u00f4les mises \u00e0 jour, g\u00e9n\u00e9ration de preuves confirm\u00e9e<\/td>\n<\/tr>\n
Mois 3<\/td>\nRem\u00e9dier les lacunes de priorit\u00e9 Moyenne ; commencer la validation de la collecte de preuves<\/td>\nTous les contr\u00f4les op\u00e9rationnels, r\u00e9cup\u00e9ration des preuves test\u00e9e<\/td>\n<\/tr>\n
Mois 4<\/td>\nMener une \u00e9valuation interne de simulation utilisant la m\u00e9thodologie d’\u00e9chantillonnage des auditeurs<\/td>\nRapport d’\u00e9valuation interne avec constats<\/td>\n<\/tr>\n
Mois 5<\/td>\nTraiter les constats de simulation ; former les \u00e9quipes \u00e0 la production de preuves et \u00e0 la pr\u00e9paration aux entretiens<\/td>\nRem\u00e9diation compl\u00e8te, sessions de pr\u00e9paration des \u00e9quipes men\u00e9es<\/td>\n<\/tr>\n
Mois 6<\/td>\nRevue finale de pr\u00e9paration ; confirmer que tous les flux de preuves sont actifs et complets<\/td>\nConfirmation de pr\u00e9paration, index des preuves, liste de points de contact pour les auditeurs<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Ressources connexes<\/h2>\n