Objectif de cette évaluation de préparation
Cette checklist d’auto-évaluation est conçue pour les organisations se préparant à un examen SOC 2 Type II incluant les pipelines CI/CD dans le périmètre d’audit. Utilisez-la pour identifier les lacunes de contrôle, prioriser les efforts de remédiation et établir la confiance que votre environnement de pipeline résistera à l’examen des auditeurs.
Pour chaque élément de la checklist, évaluez votre état actuel comme Oui (entièrement implémenté et documenté), Partiel (partiellement implémenté ou manquant de preuves), ou Non (non implémenté). Les éléments évalués comme Partiel ou Non nécessitent une remédiation avant le début de la période d’audit.
CC6 : checklist des contrôles d’accès
| # | Élément de contrôle | Statut (O/P/N) | Preuves requises | Orientations de remédiation |
|---|---|---|---|---|
| 6.1 | Le RBAC est configuré sur toutes les plateformes de pipeline (dépôt, système de build, registre d’artefacts, outils de déploiement) | Exports de configuration RBAC, document de définition des rôles | Définir les rôles standard (développeur, relecteur, approbateur, admin) et les mapper au modèle de permissions de chaque plateforme | |
| 6.2 | Le MFA est appliqué pour tous les comptes humains accédant aux systèmes de pipeline | Configuration de politique MFA, rapports d’inscription, journal d’exceptions | Activer le MFA à l’échelle de l’organisation ; documenter toute exception technique avec des contrôles compensatoires | |
| 6.3 | Les comptes de service suivent le principe de moindre privilège avec justification documentée pour chaque permission | Inventaire des comptes de service, matrice de justification des permissions | Auditer tous les comptes de service ; supprimer les permissions inutiles ; documenter la justification métier des permissions restantes | |
| 6.4 | Des revues d’accès trimestrielles sont planifiées et couvrent tous les systèmes de pipeline | Calendrier de revue, registres de revues achevées, preuves de remédiation | Établir des événements récurrents au calendrier ; assigner des responsables de revue ; créer un modèle de revue standard | |
| 6.5 | Les procédures d’intégration/départ incluent le provisionnement et le dé-provisionnement des accès aux systèmes de pipeline | Documentation d’intégration RH, checklists de dé-provisionnement, registres de délais | Ajouter les systèmes de pipeline aux checklists d’intégration/départ IT ; automatiser dans la mesure du possible | |
| 6.6 | Les procédures d’accès d’urgence et de break-glass sont documentées et exigent une revue post-utilisation | Document de procédure d’accès d’urgence, journaux d’utilisation, registres de revue post-utilisation | Documenter la procédure d’accès d’urgence ; implémenter des alertes sur l’utilisation de l’accès d’urgence | |
| 6.7 | Les secrets et identifiants sont gérés par une solution dédiée de gestion des secrets (non codés en dur) | Configuration de l’outil de gestion des secrets, résultats d’analyse montrant l’absence de secrets codés en dur | Implémenter un outil de gestion des secrets ; exécuter une analyse de secrets sur tous les dépôts | |
| 6.8 | L’accès réseau à l’infrastructure de pipeline est restreint aux réseaux et au personnel autorisés | Documentation de configuration réseau, règles de pare-feu, configuration VPN/zero-trust | Implémenter les restrictions réseau ; documenter les chemins d’accès autorisés | |
| 6.9 | L’accès des runners/agents de pipeline est isolé et ne peut accéder aux ressources au-delà de leur portée définie | Configuration des runners, documentation d’isolation, preuves de segmentation réseau | Configurer l’isolation des runners ; implémenter la segmentation réseau pour les environnements de build |
CC7 : checklist des opérations système
| # | Élément de contrôle | Statut (O/P/N) | Preuves requises | Orientations de remédiation |
|---|---|---|---|---|
| 7.1 | Les changements de configuration de pipeline sont journalisés et surveillés avec des alertes pour les modifications non autorisées | Configuration de surveillance, règles d’alerte, exemples de notifications d’alerte | Implémenter la surveillance des changements de configuration ; configurer les alertes vers l’équipe sécurité | |
| 7.2 | La détection d’anomalies est en place pour l’activité inhabituelle de pipeline (builds hors heures, patterns de déploiement inhabituels) | Règles de détection d’anomalies, documentation de référence, historique des alertes | Définir les références de comportement normal du pipeline ; configurer les alertes d’anomalies | |
| 7.3 | Les incidents de pipeline sont intégrés au programme de réponse aux incidents de l’organisation | Plan de réponse aux incidents couvrant CI/CD, critères de classification des incidents, procédures d’escalade | Mettre à jour le plan de réponse aux incidents pour inclure les scénarios CI/CD ; former l’équipe de réponse aux incidents spécifiques au pipeline | |
| 7.4 | La capacité de l’infrastructure de pipeline est surveillée et gérée pour prévenir la dégradation | Tableaux de bord de surveillance de capacité, politiques de mise à l’échelle, documents de planification de capacité | Implémenter la surveillance de capacité ; établir les seuils et procédures de mise à l’échelle | |
| 7.5 | Des procédures de sauvegarde et de récupération existent pour la configuration et l’infrastructure de pipeline | Calendriers de sauvegarde, procédures de récupération, résultats de tests de récupération | Implémenter les sauvegardes de configuration de pipeline ; documenter et tester les procédures de récupération | |
| 7.6 | La journalisation est centralisée avec des périodes de rétention définies répondant aux exigences d’audit | Configuration d’agrégation de journaux, documentation de politique de rétention, vérification du stockage | Centraliser les journaux de pipeline ; configurer la rétention pour couvrir la période d’audit plus une marge | |
| 7.7 | Les alertes d’événements de sécurité ont des procédures de réponse définies et des responsables assignés | Playbooks de réponse aux alertes, affectations de responsables, SLA de temps de réponse | Créer des playbooks de réponse pour chaque type d’alerte ; assigner et former les responsables |
CC8 : checklist de gestion des changements
| # | Élément de contrôle | Statut (O/P/N) | Preuves requises | Orientations de remédiation |
|---|---|---|---|---|
| 8.1 | Tous les changements de production nécessitent une revue de code par les pairs par un relecteur qualifié qui n’est pas l’auteur | Règles de protection de branche, paramètres de merge request, exemples de registres de revue | Configurer la protection de branche ; appliquer les exigences minimales de relecteur | |
| 8.2 | Une approbation formelle est requise avant le déploiement en production, avec approbation documentée et attribuée | Configuration d’approbation de déploiement, journaux d’approbation avec horodatages et identité de l’approbateur | Implémenter les portes d’approbation de déploiement ; s’assurer que les approbations sont journalisées avec attribution | |
| 8.3 | La séparation des fonctions est appliquée — l’auteur ne peut pas approuver ou déployer ses propres changements | Configuration d’application de la séparation des fonctions, rapports de validation montrant l’absence d’auto-approbations | Configurer l’application technique empêchant l’auto-approbation ; exécuter des rapports de validation | |
| 8.4 | L’analyse de sécurité automatisée (SAST, SCA, détection de secrets) s’exécute sur chaque changement avec des seuils définis | Configuration de pipeline montrant les étapes d’analyse, paramètres de seuils, journaux d’application des portes | Intégrer les outils d’analyse de sécurité ; définir des seuils basés sur la sévérité ; configurer les portes de blocage | |
| 8.5 | Les portes de tests automatisés empêchent le déploiement lorsque les critères qualité ne sont pas remplis | Configuration des portes de test, journaux de passage/échec, rapports de couverture de tests | Définir les critères qualité minimaux ; configurer l’application automatisée | |
| 8.6 | Les procédures de rollback sont documentées, testées et peuvent être exécutées dans les délais définis | Documentation des procédures de rollback, registres de tests, mesures de temps d’exécution | Documenter les procédures de rollback ; planifier et mener des tests de rollback | |
| 8.7 | Les procédures de changements d’urgence sont documentées avec des contrôles renforcés (revue post-implémentation, approbation accélérée) | Document de procédure de changement d’urgence, journal des changements d’urgence, registres de revue post-implémentation | Définir la procédure de changement d’urgence ; implémenter le suivi et la revue post-implémentation obligatoire | |
| 8.8 | La séparation des environnements empêche les changements de développement/test d’affecter directement la production | Documentation de l’architecture des environnements, restrictions d’accès entre environnements | Implémenter la séparation des environnements ; restreindre l’accès production à l’automatisation de déploiement | |
| 8.9 | Les registres de changements fournissent une traçabilité complète de l’exigence au déploiement en production | Exemples de registres de changements montrant la traçabilité de bout en bout, configuration de liaison des outils | Configurer la liaison ticket-déploiement ; s’assurer que tous les changements référencent un élément de travail suivi | |
| 8.10 | Les changements pipeline-as-code sont soumis au même processus de revue et d’approbation que les changements applicatifs | Protection de branche sur les fichiers de configuration de pipeline, registres de revue des changements de pipeline | Étendre la protection de branche aux fichiers de définition de pipeline ; traiter comme des changements de production |
CC9 : checklist d’atténuation des risques
| # | Élément de contrôle | Statut (O/P/N) | Preuves requises | Orientations de remédiation |
|---|---|---|---|---|
| 9.1 | Un inventaire complet des composants tiers et dépendances consommés par le pipeline existe | Software Bill of Materials (SBOM), rapports d’inventaire des dépendances | Implémenter la génération de SBOM ; exécuter l’inventaire des dépendances sur tous les projets | |
| 9.2 | L’analyse automatisée des dépendances identifie les vulnérabilités connues avec des SLA de remédiation définis | Configuration d’analyse, rapports de vulnérabilités, documentation des SLA, suivi de remédiation | Implémenter l’analyse des dépendances ; définir des SLA de remédiation basés sur la sévérité | |
| 9.3 | Les fournisseurs SaaS de pipeline ont été évalués pour la sécurité et leurs rapports SOC 2 examinés | Registres d’évaluation fournisseur, revues de rapports SOC 2, documentation d’acceptation des risques | Demander les rapports SOC 2 de tous les fournisseurs de pipeline ; mener et documenter les évaluations | |
| 9.4 | Les risques d’infrastructure partagée (runners partagés, environnements de build multi-locataires) sont évalués et atténués | Documentation d’évaluation des risques, contrôles d’atténuation, vérification d’isolation | Évaluer les risques d’infrastructure partagée ; implémenter des runners dédiés si le risque le justifie | |
| 9.5 | La conformité des licences pour les composants open-source est surveillée et gérée | Configuration d’analyse de licences, rapports de conformité, liste de licences approuvées | Implémenter l’analyse de licences ; définir la liste de licences approuvées ; établir un processus de revue pour les exceptions | |
| 9.6 | Les vecteurs d’attaque de la chaîne d’approvisionnement (dependency confusion, paquets compromis) sont évalués avec des contrôles préventifs | Documentation d’évaluation des menaces, configuration de registre privé, paramètres de vérification de paquets | Implémenter des registres privés ou des proxys ; configurer la vérification de signature des paquets | |
| 9.7 | L’accès des intégrations tierces (webhooks, tokens API, applications OAuth) est inventorié et revu périodiquement | Inventaire des intégrations, documentation des portées d’accès, registres de revue périodique | Inventorier toutes les intégrations ; documenter les portées d’accès ; planifier des revues périodiques |
Analyse des lacunes : comment prioriser la remédiation
Après avoir complété l’évaluation, catégorisez les constats en utilisant le cadre de priorité suivant :
| Priorité | Critères | Délai de remédiation | Exemples |
|---|---|---|---|
| Critique | Contrôle absent ; affecte directement l’opinion d’audit | Immédiat (dans les 2 semaines) | Pas d’application d’approbation, pas de revues d’accès, pas de journalisation |
| Élevé | Contrôle partiellement implémenté ; lacunes dans les preuves | Dans les 30 jours | MFA non universel, revues incomplètes, certains systèmes exclus |
| Moyen | Contrôle existant mais qualité des preuves insuffisante | Dans les 60 jours | Preuves manuelles, documentation incomplète, processus informels |
| Faible | Opportunité d’amélioration du contrôle ; non critique pour l’audit | Dans les 90 jours | Améliorations d’automatisation, surveillance supplémentaire, rapports améliorés |
Calendrier de préparation recommandé (6 mois avant l’audit)
| Période | Activité | Livrable |
|---|---|---|
| Mois 1 | Compléter cette évaluation de préparation ; identifier toutes les lacunes | Checklist complétée avec analyse des lacunes et plan de remédiation priorisé |
| Mois 2 | Remédier les lacunes de priorité Critique et Élevée | Implémentations de contrôles mises à jour, génération de preuves confirmée |
| Mois 3 | Remédier les lacunes de priorité Moyenne ; commencer la validation de la collecte de preuves | Tous les contrôles opérationnels, récupération des preuves testée |
| Mois 4 | Mener une évaluation interne de simulation utilisant la méthodologie d’échantillonnage des auditeurs | Rapport d’évaluation interne avec constats |
| Mois 5 | Traiter les constats de simulation ; former les équipes à la production de preuves et à la préparation aux entretiens | Remédiation complète, sessions de préparation des équipes menées |
| Mois 6 | Revue finale de préparation ; confirmer que tous les flux de preuves sont actifs et complets | Confirmation de préparation, index des preuves, liste de points de contact pour les auditeurs |
Ressources connexes
- Hub de conformité SOC 2
- Playbook du jour d’audit — Comment gérer les audits CI/CD dans les environnements réglementés
Ressources connexes pour les auditeurs
- Glossaire — Définitions en langage clair des termes techniques
- Playbook du jour d’audit
- Comment les auditeurs examinent les pipelines CI/CD
- Contrôles de sécurité CI/CD fondamentaux
Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.
