Contrôles des risques ICT tiers pour les pipelines CI/CD réglementés
Pourquoi cette checklist existe
Dans les environnements réglementés, les fournisseurs ne sont pas « externes ». Ils font partie de votre système de livraison.
Lorsque des services tiers supportent votre SDLC (hébergement Git, CI/CD SaaS, registres d’artefacts, runtime cloud, scanners de sécurité), les auditeurs s’attendent à ce que vous démontriez :
- La gouvernance des fournisseurs (inventaire, classification, contrats, plans de sortie)
- Les contrôles techniques CI/CD (isolation des accès, application des politiques, rétention des preuves)
- La surveillance continue et la responsabilité (sous-traitants, SLA, incidents)
Cette checklist est conçue pour être utilisée par les équipes sécurité, ingénierie, risques et audit comme référentiel de contrôle commun.
Périmètre : fournisseurs impactant typiquement le CI/CD
Utilisez cette checklist pour tout fournisseur fournissant :
- Hébergement Git (GitHub/GitLab SaaS)
- Plateforme CI/CD (GitHub Actions, GitLab CI SaaS, CircleCI, etc.)
- Runners (runners hébergés / partagés / cloud)
- Registres d’artefacts (conteneurs / Maven / registres binaires)
- Proxys et miroirs de dépendances
- Runtime cloud / Kubernetes managé / PaaS
- Outils de sécurité SaaS (SAST/DAST/SCA, scan de secrets)
- Observabilité et journalisation SaaS (SIEM / monitoring)
1) Inventaire et propriété des fournisseurs
✅ Checklist
- Un inventaire complet des fournisseurs utilisés dans le SDLC/CI/CD existe (y compris les usages non déclarés).
- Chaque fournisseur a un propriétaire métier et un propriétaire technique désignés.
- L’inventaire capture où le fournisseur intervient (Git, CI, registre, runtime, journalisation).
- La criticité est définie par fournisseur (impact en cas d’indisponibilité/compromission).
- Les localisations des données et le modèle d’hébergement des fournisseurs sont documentés (UE/US, multi-région, etc.).
- Les chemins d’accès tiers à vos systèmes sont répertoriés (SSO, tokens API, agents, webhooks).
Exemples de preuves
- Tableur d’inventaire des fournisseurs / entrée CMDB
- Carte d’architecture montrant les points de contact fournisseurs
- Registre de propriété (RACI)
2) Classification des risques fournisseurs
✅ Checklist
- Une classification formelle des risques existe (Critique / Élevé / Moyen / Faible).
- L’évaluation des risques inclut confidentialité, intégrité, disponibilité et impact réglementaire.
- Les fournisseurs CI/CD et d’artefacts sont traités comme critiques pour l’intégrité par défaut.
- La classification des risques détermine les exigences de contrôle obligatoires (ex. : journalisation renforcée, plan de sortie).
- La classification des risques est révisée au moins annuellement ou lors de changements majeurs.
Exemples de preuves
- Rapport d’évaluation des risques / questionnaire
- Méthodologie de risques tiers
- Horodatages et approbations des revues
3) Base contractuelle (sécurité + auditabilité)
✅ Checklist
- Le contrat inclut des obligations de sécurité (contrôles de base, gestion des vulnérabilités, chiffrement).
- Le contrat inclut des droits d’audit ou un mécanisme d’assurance équivalent.
- Le contrat inclut des délais de notification de violation/incident (y compris les critères de matérialité).
- Le contrat inclut des obligations de divulgation des sous-traitants.
- Le contrat inclut des exigences de rétention et de suppression des données.
- Le contrat inclut des attentes de continuité de service (PCA/PRA).
- Le contrat inclut des clauses de sortie/transition (export de données, support de migration).
Exemples de preuves
- Clauses contractuelles signées (annexe sécurité)
- Registre des sous-traitants
- Clause SLA de notification d’incident
4) Identité, accès et isolation (application technique)
✅ Checklist
- Le SSO est imposé pour les consoles d’administration des fournisseurs lorsque possible.
- Le MFA est obligatoire pour les comptes privilégiés.
- Les rôles sont minimaux et mappés aux besoins métier (moindre privilège).
- Les revues d’accès sont effectuées régulièrement (trimestriellement pour les fournisseurs critiques).
- Les runners CI/CD sont isolés (pas de runners partagés pour les charges sensibles).
- Les secrets ne sont pas stockés dans les interfaces fournisseurs sauf contrôle (utiliser vault/injection).
- Les tokens tiers sont limités en périmètre, renouvelés et surveillés.
Exemples de preuves
- Exports de politiques IAM / captures d’écran
- Journaux de revue d’accès
- Configuration des runners montrant l’isolation
- Politique de rotation des tokens + preuve
5) Application des politiques pipeline (barrières incontournables)
✅ Checklist
- Des approbations obligatoires existent pour les déploiements en production.
- Les barrières de politique bloquent les releases en cas de résultats critiques de scan (SAST/SCA/DAST selon applicabilité).
- La signature des artefacts est imposée avant la promotion de release.
- La génération de SBOM est automatisée pour les releases.
- Les branches protégées / règles de merge sont appliquées pour les dépôts réglementés.
- Les exceptions sont gouvernées (limitées dans le temps, approuvées, documentées).
- Les administrateurs de pipeline ne peuvent pas désactiver silencieusement les contrôles (changements tracés).
Exemples de preuves
- Configuration du pipeline CI/CD (barrières)
- Configuration des branches protégées
- Enregistrements d’approbation de release
- Registre des exceptions
6) Génération et rétention des preuves (prêt pour l’audit par conception)
✅ Checklist
- Les journaux CI/CD sont conservés pendant une durée définie conforme aux exigences.
- Les événements d’approbation sont journalisés et exportables.
- Les résultats de scan de sécurité sont stockés de manière centralisée (pas uniquement dans les tableaux de bord des fournisseurs).
- La traçabilité existe : commit → exécution pipeline → artefact → déploiement → production.
- Le stockage des preuves est inviolable ou à accès contrôlé.
- Les exports d’audit sont testés (capacité à produire des preuves rapidement).
Exemples de preuves
- Politique de rétention des preuves
- Paramètres de rétention SIEM / configuration d’archivage
- Rapport de traçabilité (release échantillon)
- Enregistrement de test d’export (« exercice d’audit »)
7) Surveillance, incidents et responsabilité des fournisseurs
✅ Checklist
- Le fournisseur fournit des notifications d’incidents de sécurité dans le SLA défini.
- Vous surveillez le statut/disponibilité du fournisseur et intégrez les signaux dans les workflows opérationnels.
- Les anomalies de pipeline CI/CD sont surveillées (workflows inattendus, nouveaux tokens, nouveaux runners).
- Les avis de sécurité des fournisseurs sont suivis et évalués.
- Vous maintenez un playbook d’incident interne référençant les chemins d’escalade fournisseurs.
- Vous pouvez corréler les événements de pipeline et les événements fournisseurs (chronologie partagée).
Exemples de preuves
- Tableaux de bord de surveillance + règles d’alerte
- Plan de réponse aux incidents avec contacts fournisseurs
- Post-mortems référençant l’implication des fournisseurs
- Tickets de suivi des avis de sécurité
8) Visibilité des sous-traitants (profondeur de la chaîne d’approvisionnement)
✅ Checklist
- Le fournisseur fournit une liste actualisée des sous-traitants.
- Les changements de sous-traitants sont notifiés et examinés.
- Les sous-traitants critiques font l’objet d’une évaluation des risques.
- Les flux de données impliquant des sous-traitants sont compris.
- Les contrats incluent des obligations relatives aux sous-traitants (sécurité & notification).
Exemples de preuves
- Export de la liste des sous-traitants
- Enregistrement de la revue des risques
- Diagrammes de flux de données
9) Test de la stratégie de sortie (réalisme PRA & PCA)
✅ Checklist
- Vous disposez d’un plan de sortie documenté pour chaque fournisseur CI/CD critique.
- Vous pouvez exporter le code source, les définitions de pipeline, les artefacts et les journaux.
- Vous disposez d’un chemin de migration testé (CI/CD alternatif, registre, modèle de runners).
- Vous effectuez des tests de sortie (exercices théoriques + techniques) à intervalles définis.
- Les attentes RTO/RPO sont documentées et validées avec des preuves.
Exemples de preuves
- Document du plan de sortie
- Journaux et captures d’écran des tests d’export
- Rapport d’exercice PRA
- Preuve de concept de migration
Tableau d’audit (Oui / Non / Notes)
| Domaine de contrôle | Vérification | Oui | Non | Notes / Lien vers preuve |
|---|---|---|---|---|
| Inventaire | Inventaire des fournisseurs complet (SDLC/CI/CD) | ☐ | ☐ | |
| Propriété | Propriétaire métier + technique défini | ☐ | ☐ | |
| Classification | Classification des risques appliquée aux fournisseurs CI/CD | ☐ | ☐ | |
| Contrats | Obligations de sécurité dans le contrat | ☐ | ☐ | |
| Contrats | Droits d’audit / mécanisme d’assurance | ☐ | ☐ | |
| Contrats | SLA de notification d’incident défini | ☐ | ☐ | |
| Contrats | Clauses de sortie incluses | ☐ | ☐ | |
| Accès | SSO imposé (si possible) | ☐ | ☐ | |
| Accès | MFA obligatoire pour les comptes privilégiés | ☐ | ☐ | |
| Accès | Rôles à moindre privilège appliqués | ☐ | ☐ | |
| Runners | Isolation des runners (pas de runners partagés) | ☐ | ☐ | |
| Secrets | Secrets injectés au runtime (vault) | ☐ | ☐ | |
| Barrières de politique | Approbations obligatoires pour la prod | ☐ | ☐ | |
| Barrières de politique | Barrières bloquantes sur les résultats critiques | ☐ | ☐ | |
| Intégrité | Signature des artefacts imposée | ☐ | ☐ | |
| Intégrité | SBOM générée automatiquement | ☐ | ☐ | |
| Preuves | Journaux conservés selon la politique | ☐ | ☐ | |
| Preuves | Enregistrements d’approbation exportables | ☐ | ☐ | |
| Preuves | Traçabilité commit→prod prouvée | ☐ | ☐ | |
| Surveillance | Anomalies fournisseurs + pipeline surveillées | ☐ | ☐ | |
| Sous-traitants | Visibilité et revue des sous-traitants | ☐ | ☐ | |
| Test de sortie | Plan de sortie testé avec preuves | ☐ | ☐ |
Guide d’implémentation technique
Cette checklist définit les attentes en matière de gouvernance.
Pour un guide pratique d’implémentation pour les ingénieurs (GitHub, GitLab, isolation des runners, barrières de politique, signature d’artefacts), consultez :
👉 Guide de remédiation pour les contrôles fournisseurs CI/CD
Cet article compagnon fournit des exemples de configuration concrets et des patrons d’implémentation.
