Contrôles du risque ICT lié aux 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 prennent en charge votre SDLC (hébergement Git, CI/CD en SaaS, registres d’artefacts, environnement d’exécution cloud, scanners de sécurité), les auditeurs attendent de vous 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, conservation des preuves)
- La surveillance continue et la responsabilisation (sous-traitants ultérieurs, SLA, incidents)
Cette checklist est conçue pour être utilisée par les équipes sécurité, ingénierie, risque et audit comme socle de contrôles partagé.
Périmètre : les fournisseurs qui influent généralement sur la CI/CD
Utilisez cette checklist pour tout fournisseur assurant :
- L’hébergement Git (GitHub/GitLab en SaaS)
- La plateforme CI/CD (GitHub Actions, GitLab CI en SaaS, CircleCI, etc.)
- Les runners (runners hébergés / runners partagés / runners cloud)
- Les registres d’artefacts (registres de conteneurs / Maven / binaires)
- Les proxys et miroirs de dépendances
- L’environnement d’exécution cloud / Kubernetes managé / PaaS
- Les outils de sécurité en SaaS (SAST/DAST/SCA, détection de secrets)
- L’observabilité et la journalisation en SaaS (SIEM / supervision)
1) Inventaire des fournisseurs et responsabilités
✅ Checklist
- Un inventaire complet des fournisseurs utilisés à travers le SDLC/CI/CD existe (y compris les usages informels).
- Chaque fournisseur dispose d’un responsable métier et d’un responsable technique nommément désignés.
- L’inventaire précise où se situe le fournisseur (Git, CI, registre, exécution, journalisation).
- La criticité est définie pour chaque fournisseur (impact en cas d’indisponibilité/de compromission).
- Les localisations des données et le modèle d’hébergement du fournisseur sont documentés (UE/US, multi-région, etc.).
- Les chemins d’accès des tiers à vos systèmes sont recensés (SSO, jetons d’API, agents, webhooks).
Exemples de preuves
- Tableur d’inventaire des fournisseurs / entrée de CMDB
- Cartographie d’architecture montrant les points de contact fournisseurs
- Registre des responsabilités (RACI)
2) Classification du risque fournisseur
✅ Checklist
- Une classification formelle du risque existe (Critique / Élevé / Moyen / Faible).
- La notation du risque intègre la confidentialité, l’intégrité, la disponibilité et l’impact réglementaire.
- Les fournisseurs de CI/CD et d’artefacts sont traités comme critiques pour l’intégrité par défaut.
- La notation du risque conditionne les exigences de contrôle obligatoires (par exemple, une journalisation renforcée, un plan de sortie).
- La notation du risque est réexaminée au moins une fois par an ou lors d’un changement majeur.
Exemples de preuves
- Rapport d’évaluation du risque / questionnaire
- Méthodologie de risque tiers
- Horodatages et approbations des revues
3) Socle contractuel (sécurité + auditabilité)
✅ Checklist
- Le contrat prévoit des obligations de sécurité (contrôles de base, gestion des vulnérabilités, chiffrement).
- Le contrat prévoit des droits d’audit ou un mécanisme d’assurance équivalent.
- Le contrat prévoit des délais de notification des violations/incidents (y compris les critères de matérialité).
- Le contrat prévoit des obligations de divulgation des sous-traitants ultérieurs.
- Le contrat prévoit des exigences de conservation et de suppression des données.
- Le contrat prévoit des attentes de continuité de service (PCA/PRA).
- Le contrat prévoit des modalités de sortie/transition (export des données, accompagnement à la migration).
Exemples de preuves
- Clauses contractuelles signées (annexe de sécurité)
- Registre des sous-traitants ultérieurs
- Clause de 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 c’est possible.
- La MFA est obligatoire pour les comptes à privilèges.
- Les rôles sont minimaux et alignés sur les besoins des postes (moindre privilège).
- Des revues d’accès sont menées régulièrement (trimestriellement pour les fournisseurs critiques).
- Les runners CI/CD sont isolés (pas de runners partagés pour les charges de travail sensibles).
- Les secrets ne sont pas stockés dans les interfaces des fournisseurs, sauf de manière contrôlée (coffre-fort/injection).
- Les jetons des tiers sont limités en portée, renouvelés et surveillés.
Exemples de preuves
- Exports / captures d’écran des politiques IAM
- Journaux des revues d’accès
- Configuration des runners démontrant l’isolation
- Politique de rotation des jetons + preuve
5) Application des politiques du pipeline (des gates qui ne peuvent être contournés)
✅ Checklist
- Des approbations obligatoires existent pour les déploiements en production.
- Des gates de politique bloquent les mises en production en cas d’échec critique des scans (SAST/SCA/DAST selon le cas).
- La signature des artefacts est imposée avant la promotion d’une mise en production.
- La génération de la SBOM est automatisée pour les mises en production.
- Les branches protégées / règles de fusion sont imposées pour les dépôts réglementés.
- Les dérogations sont encadrées (limitées dans le temps, approuvées, documentées).
- Les administrateurs du pipeline ne peuvent pas désactiver les contrôles en silence (modifications tracées).
Exemples de preuves
- Configuration du pipeline CI/CD (gates)
- Configuration des branches protégées
- Enregistrements des approbations de mise en production
- Registre des dérogations
6) Génération et conservation des preuves (prêt pour l’audit par conception)
✅ Checklist
- Les journaux CI/CD sont conservés pendant une durée définie, alignée sur les exigences.
- Les événements d’approbation sont journalisés et exportables.
- Les résultats des scans de sécurité sont stockés de manière centralisée (pas seulement dans les tableaux de bord des fournisseurs).
- La traçabilité existe : commit → exécution du pipeline → artefact → déploiement → production.
- Le magasin de preuves est inviolable ou à accès contrôlé.
- Les exports d’audit sont testés (capacité à produire rapidement des preuves).
Exemples de preuves
- Politique de conservation des preuves
- Paramètres de conservation du SIEM / configuration d’archivage
- Rapport de traçabilité (mise en production échantillon)
- Compte rendu de test d’export (« exercice d’audit »)
7) Surveillance, incidents et responsabilité du fournisseur
✅ Checklist
- Le fournisseur fournit des notifications d’incident de sécurité dans le SLA défini.
- Vous surveillez l’état/la disponibilité du fournisseur et intégrez ces signaux dans vos flux opérationnels.
- Les anomalies du pipeline CI/CD sont surveillées (workflows inattendus, nouveaux jetons, nouveaux runners).
- Les avis de sécurité du fournisseur sont suivis et évalués.
- Vous tenez à jour un manuel interne de gestion des incidents référençant les voies d’escalade du fournisseur.
- Vous pouvez corréler les événements du pipeline et les événements du fournisseur (chronologie partagée).
Exemples de preuves
- Tableaux de bord de surveillance + règles d’alerte
- Plan de réponse aux incidents avec les contacts fournisseurs
- Post-mortems mentionnant l’implication du fournisseur
- Tickets de suivi des avis de sécurité
8) Visibilité sur les sous-traitants ultérieurs (profondeur de la chaîne d’approvisionnement)
✅ Checklist
- Le fournisseur fournit une liste à jour de ses sous-traitants ultérieurs.
- Les changements de sous-traitants ultérieurs sont notifiés et réexaminés.
- Les sous-traitants ultérieurs critiques font l’objet d’une évaluation du risque.
- Les flux de données impliquant des sous-traitants ultérieurs sont compris.
- Les contrats prévoient des obligations pour les sous-traitants ultérieurs (sécurité & notification).
Exemples de preuves
- Export de la liste des sous-traitants ultérieurs
- Compte rendu de revue du risque
- Diagrammes de flux de données
9) Test de la stratégie de sortie (réalisme du PRA & du 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, registre, modèle de runner alternatifs).
- Vous menez des tests de sortie (exercices sur table + exercices techniques) à intervalles définis.
- Les attentes de RTO/RPO sont documentées et validées par des preuves.
Exemples de preuves
- Document de plan de sortie
- Journaux et captures d’écran des tests d’export
- Rapport d’exercice de PRA
- Preuve de concept de migration
Tableau d’audit (Oui / Non / Notes)
| Domaine de contrôle | Vérification | Oui | Non | Notes / Lien vers la preuve |
|---|---|---|---|---|
| Inventaire | Inventaire des fournisseurs complet (SDLC/CI/CD) | ☐ | ☐ | |
| Responsabilités | Responsable métier + technique désignés | ☐ | ☐ | |
| Classification | Hiérarchisation du risque 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é (lorsque c’est possible) | ☐ | ☐ | |
| Accès | MFA obligatoire pour les comptes à privilèges | ☐ | ☐ | |
| Accès | Rôles à moindre privilège imposés | ☐ | ☐ | |
| Runners | Isolation des runners (pas de runners partagés) | ☐ | ☐ | |
| Secrets | Secrets injectés à l’exécution (coffre-fort) | ☐ | ☐ | |
| Gates de politique | Approbations obligatoires pour la production | ☐ | ☐ | |
| Gates de politique | Gates bloquants en cas de findings 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 démontrée | ☐ | ☐ | |
| Surveillance | Anomalies fournisseur + pipeline surveillées | ☐ | ☐ | |
| Sous-traitants ultérieurs | Visibilité + revue des sous-traitants ultérieurs | ☐ | ☐ | |
| Test de sortie | Plan de sortie testé avec preuves | ☐ | ☐ |
La version auditeur stricte
La checklist ci-dessus reflète un socle sain. Un auditeur exigeant — en particulier dans le cadre de DORA, de NIS2 ou d’une mission ISO 27001 ou SOC 2 rigoureuse — va plus loin : chaque contrôle doit porter un responsable désigné, une référence de preuve précise et une décision documentée à l’issue de la revue. Cette grille plus stricte réorganise les mêmes attentes dans un format d’évaluation qu’un auditeur peut compléter en séance, en consignant une référence de preuve face à chaque ligne plutôt qu’en se contentant d’une assurance verbale.
Utilisez la colonne Référence de preuve pour pointer vers l’artefact exact — un export de journaux, une capture d’écran de configuration, une clause contractuelle signée ou un ticket — qui atteste du contrôle. Une référence laissée vide est traitée comme un écart, non comme une validation.
Section A — Gouvernance & inventaire
Un auditeur strict commence par confirmer que la population de fournisseurs est entièrement connue et sous responsabilité désignée. Les lacunes à ce niveau minent tous les contrôles en aval, car un fournisseur que vous n’avez pas inventorié ne peut être gouverné, surveillé ni faire l’objet d’une sortie.
| Contrôle | Oui | Non | Référence de preuve |
|---|---|---|---|
| Un inventaire complet des fournisseurs liés à la CI/CD existe | ☐ | ☐ | |
| Classification de la criticité des fournisseurs définie | ☐ | ☐ | |
| Responsable métier formellement désigné | ☐ | ☐ | |
| Responsable technique formellement désigné | ☐ | ☐ | |
| Évaluation annuelle du risque réalisée | ☐ | ☐ | |
| Liste des sous-traitants ultérieurs documentée | ☐ | ☐ |
Section B — Contrôles contractuels & réglementaires
Au-delà des mesures techniques, le contrat doit vous accorder des droits contraignants. L’auditeur vérifie que les obligations d’assurance, de notification des violations, de localisation des données et de sortie sont inscrites dans l’accord, et non supposées à partir du discours commercial d’un fournisseur.
| Contrôle | Oui | Non | Référence de preuve |
|---|---|---|---|
| Obligations de sécurité incluses dans le contrat | ☐ | ☐ | |
| SLA de notification d’incident défini | ☐ | ☐ | |
| Clause de droits d’audit présente | ☐ | ☐ | |
| Transparence sur la localisation des données incluse | ☐ | ☐ | |
| Clause de stratégie de sortie définie contractuellement | ☐ | ☐ |
Section C — Application technique en CI/CD
Ici, l’auditeur vérifie que la gouvernance est réellement appliquée dans le pipeline, et pas seulement documentée. Chaque contrôle doit être démontrable dans la configuration en vigueur.
| Contrôle | Oui | Non | Référence de preuve |
|---|---|---|---|
| SSO imposé sur les comptes d’administration CI/CD | ☐ | ☐ | |
| MFA obligatoire pour les rôles à privilèges | ☐ | ☐ | |
| Accès basé sur les rôles avec moindre privilège | ☐ | ☐ | |
| Branches protégées imposées | ☐ | ☐ | |
| Approbations de production obligatoires configurées | ☐ | ☐ | |
| Les gates de politique bloquent les findings critiques | ☐ | ☐ | |
| Signature des artefacts imposée | ☐ | ☐ | |
| Génération de la SBOM automatisée | ☐ | ☐ | |
| Isolation des runners mise en œuvre | ☐ | ☐ |
Section D — Preuves & conservation
L’auditeur confirme que vous pouvez produire des preuves à la demande et qu’elles sont conservées suffisamment longtemps pour couvrir toute la période de revue, indépendamment du tableau de bord d’un fournisseur particulier.
| Contrôle | Oui | Non | Référence de preuve |
|---|---|---|---|
| Journaux CI/CD conservés selon la politique | ☐ | ☐ | |
| Journaux d’approbation exportables | ☐ | ☐ | |
| Résultats des scans de sécurité archivés de manière centralisée | ☐ | ☐ | |
| Traçabilité complète commit → artefact → prod | ☐ | ☐ | |
| Durée de conservation des preuves documentée | ☐ | ☐ |
Section E — Stratégie de sortie & tests de PRA
Enfin, l’auditeur cherche la preuve que la dépendance au fournisseur a été testée, et pas seulement planifiée — des chemins d’export et de migration qui ont réellement été exercés et étayés par des preuves.
| Contrôle | Oui | Non | Référence de preuve |
|---|---|---|---|
| Un plan de sortie documenté existe | ☐ | ☐ | |
| Export du code testé | ☐ | ☐ | |
| Export de la configuration du pipeline testé | ☐ | ☐ | |
| Export des artefacts testé | ☐ | ☐ | |
| Exercice de PRA / migration réalisé | ☐ | ☐ |
Bloc de décision de l’auditeur
Une revue exigeante se conclut par une décision documentée plutôt que par une liste ouverte d’observations. Consigner ces quatre lignes transforme la grille en une conclusion d’audit défendable :
- Notation globale du risque : ___
- Findings critiques : ___
- Remédiation exigée pour le : ___
- Date de l’audit de suivi : ___
Guide de mise en œuvre technique
Cette checklist définit les attentes de gouvernance.
Pour un guide pratique de mise en œuvre côté ingénierie (GitHub, GitLab, isolation des runners, gates de politique, signature des artefacts), voir :
👉 Engineer Remediation Guide for CI/CD Supplier Controls
Cet article complémentaire fournit des exemples de configuration concrets et des modèles de mise en œuvre.
