Cette checklist met en évidence les signaux d’alerte courants liés au CI/CD au titre de DORA Article 28.
Chaque élément représente une situation fréquemment identifiée lors d’audits comme une défaillance de risque ICT tiers.
Si un ou plusieurs éléments s’appliquent, les auditeurs peuvent classer la plateforme CI/CD ou le fournisseur comme à haut risque ou non conforme.
Checklist des signaux d’alerte tiers CI/CD (Revue rapide)
Gouvernance et stratégie de sortie
- ⬜ Aucun plan de sortie documenté pour les plateformes CI/CD SaaS
- ⬜ Le plan de sortie existe mais n’a jamais été testé techniquement
- ⬜ Aucune capacité d’exporter les logs et artefacts CI/CD historiques
- ⬜ Les pipelines ne peuvent pas être redéployés sur une plateforme alternative
Infrastructure CI/CD et isolation
- ⬜ Les tâches CI s’exécutent sur des runners partagés ou mutualisés sans garanties claires d’isolation
- ⬜ Les mécanismes d’isolation des runners sont non documentés ou inconnus
- ⬜ L’environnement d’exécution CI est entièrement contrôlé par le fournisseur
- ⬜ Les secrets sont exposés à des contextes d’exécution tiers
Visibilité sur les fournisseurs et sous-traitants
- ⬜ Le fournisseur CI/CD SaaS n’est pas répertorié dans l’inventaire des tiers ICT
- ⬜ Les sous-traitants (cloud, runners, registres) ne sont pas identifiés
- ⬜ Aucune classification des risques pour les tiers liés au CI/CD
- ⬜ La criticité du fournisseur n’influence pas les contrôles appliqués
Contrôles contractuels et juridiques
- ⬜ Les contrats CI/CD n’incluent pas de droits d’audit ou d’inspection
- ⬜ Les droits d’audit existent mais ne sont pas pratiquement applicables
- ⬜ Aucun SLA contractuel de notification d’incident
- ⬜ Les clauses de sortie et de résiliation sont absentes ou floues
Preuves et auditabilité
- ⬜ Les logs CI/CD sont conservés pendant une période courte ou indéfinie
- ⬜ Les enregistrements d’approbation et de modification ne sont pas traçables
- ⬜ Les métadonnées et la provenance des artefacts sont absentes
- ⬜ Les preuves sont collectées manuellement uniquement lors des audits
Gouvernance CI/CD et application des politiques
- ⬜ Aucune porte d’approbation pour les modifications de pipeline
- ⬜ Utilisation non restreinte des plugins ou actions de la marketplace
- ⬜ Aucun verrouillage de version ni revue des composants CI/CD tiers
- ⬜ Les contrôles varient entre les pipelines sans justification
Checklist type auditeur (Oui / Non)
| Point de contrôle | Oui | Non |
|---|---|---|
| Les plateformes CI/CD sont incluses dans l’inventaire des tiers ICT | ⬜ | ⬜ |
| Les fournisseurs CI/CD sont classifiés par risque | ⬜ | ⬜ |
| Les stratégies de sortie existent et sont techniquement réalisables | ⬜ | ⬜ |
| Les runners CI sont isolés et contrôlés | ⬜ | ⬜ |
| Les sous-traitants sont identifiés et gouvernés | ⬜ | ⬜ |
| Les droits d’audit sont définis contractuellement | ⬜ | ⬜ |
| Les SLA de notification d’incident sont en place | ⬜ | ⬜ |
| Les logs CI/CD sont conservés et protégés | ⬜ | ⬜ |
| Les approbations et portes de politique sont appliquées | ⬜ | ⬜ |
| Les preuves peuvent être produites à la demande | ⬜ | ⬜ |
Signaux d’alerte expliqués (Interprétation d’audit)
| Signal d’alerte | Pourquoi les auditeurs s’en soucient | Contrôle attendu |
|---|---|---|
| Absence de plan de sortie | Risque de verrouillage fournisseur | Stratégie de sortie technique testée |
| Runners partagés | Risque de confidentialité et d’intégrité | Runners isolés ou dédiés |
| Absence de visibilité sur les sous-traitants | Exposition au risque cachée | Cartographie complète de la chaîne d’approvisionnement |
| Absence de droits d’audit | Aucune vérification indépendante | Clauses d’audit applicables |
| Absence de conservation des preuves | Les contrôles ne peuvent pas être prouvés | Conservation automatisée des logs |
Comment les auditeurs utilisent cette checklist
Les auditeurs ne s’attendent pas à un risque nul.
Ils s’attendent à ce que :
- les risques soient identifiés,
- les contrôles soient appliqués,
- les preuves soient disponibles et cohérentes.
Plusieurs éléments non cochés dans la même catégorie entraînent souvent :
- une classification à haut risque,
- des plans de remédiation,
- des audits de suivi.
Comment utiliser cette checklist en interne
Utilisation recommandée :
- l’exécuter avant un audit,
- l’exécuter après l’intégration d’un nouveau fournisseur CI/CD,
- l’inclure dans les revues des risques tiers,
- la relier à votre Checklist de sécurité CI/CD et à votre Pack de preuves.
Contenu associé
- Third-Party Risk in CI/CD Pipelines under DORA Article 28
- DORA Article 28 Evidence Pack — What to Show Auditors
- DORA Article 28 Architecture — Explained
- CI/CD Security Checklist for Enterprises
